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LO Introduction & Table of Contents 

Nofdic is Cirrus Logic's Fourth Generation Flat Panel VGA Controller to be markettcd in 
first half of 1994. 

Nordic- 1 M is a mid-end member of the Nordic family. It is a GUI Accellerator with PCI 
support and Multi-Media Features. 

Nordic-IM is targetted for the mid to high end of the Note-book Computer Market and 
for for the energy efficient desk-top computers mother-boards. 
Nordic- IM is not targetted to the adapter market 

1.1 Table of Contents 

This Specification will address the foUowing: 

1. Introduction and Table of Contents 

2. Basic Feature Set 

3. Detailed List of Features 

4. Pinoui and Pin Description 

5. Architecture Specification 

6. Register Specification 

7. Product Implementation Plan 
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2.0 Nordic-IM Basic Feature Set 

1. Flat Panel VGA Compatible GUI Accelerator register and feature compatible to 
5428 and Alpine I A/V. Priority: A (= highest). 

2. 32bit CPU, 32bit Video Memory, 32bit BLT and 32bit CPU to Video Memory Dau 
Path. Priority: A (= highest). 

3. 208 pin QFP package. 

4. Targeted to sample CY Ql'94, production CY Q2 '94. Priority: A (= highest). 

5. Target cost: $12 to $10 *> less than 400mil [f] in C8 Foster City. 

6. Multimedia Features 

• Pan of a well defined System Solution for high performance CD-ROM video and 
audio playback for the portable market. Priority: B 

• Fan of a well defined System Solution for mid performance low cost live NTSC 
Video and Audio with the NTSC decoder on a PCMCIA card. Priority: B 

• Audio Port to Display Memory: Audio Buffer to Serial Interface for CS4248 Audio 
Codec. Priority: C (CS4215 is not fit for notebook computers). 

• Video Playback decompression acceleration for CinePak including Color Space 
Conversion (YUV -> RGB). Priority: B 

• Live Video in a 320x240 or 640x480 Window from a proprictaryly compressed TV 
decoded data source (at 3OH2) on TFT color panels. Data is stored compressed and it is 
decompressed to 18bit/pel or 24bit/pel in real time at display time. NTSC decoder and 
data compressor is on the PCMCIA card or the PCMCIA controller. Please note that 
due to live video bandwidth requirements on PCMCIA bus , a relatively non-expen- 
sive way to achieve the second feature is to implement this compression algorithm. Pri- 
ority: B 

• Color Key Live Video Overlay based on a 5428-like Feature Connector with PCI bus 
(only). 

7. Integrated in Nordic l-M Cirrus Confidential 

• Color Space Converter for CinePak. Priority: B Business Information 

• 1 8bit DAC with direct color capability Priority: A 146367 

• 24bit RAMDAC with true color capability Priority: C 

• Clock Synthesizers for Video and Memory Clock (65MHz/3V, 1 10MH2/4.5V). Prior- 
ity: A 
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• DAC IRcf Current Source on chip. Priority: C. Boyd and ManShek are working on it. 

8. Direct Bus Interface: 

• 32bit VESA- VL bus (and 486 local bus) Priority: A 

• 32bit PCI bus. No on chip BIOS ROM suppon in PCI. Priority: A 

• 16bit ISA bus for demonstration and easy system validation. Priority: B 

• 32K or 48KB BIOS ROM suppon in ISA and VESA VL bus. Priority: B (onJy for 
BIOS/ system debug) 

• At least 5 scratch pad registers: optimum 8 scratch pad registers. Priority: A. 

9. Performance Enhancements to achieve 15-20MWinmarks at lKx768 8b/pel: 

• 32bit BitBLT with memory mapped I/O BitBLT registers (as in 5428 ?or Alpine) Prior- 
ity:A 

• BLT buffer of 8 (ei^ ) bytes for Source (and Destination ?) data, (5428 buffer is 
Sbytes, Alpine is 16bytes) (as 5428) 

• X/Y offset for Pattern BLT (as in Alpine) Priority: C 

• h/w graphic cursor 64x64 (as in 5428) 

• color expansion (as in 5428) 

• linear memory addressing (as in 5428) 

• 4 stage 32bit wide write buffer and capability to page CPU cycles if accumulated in the 
write buffer (this is already in 5428) 

10. Display Memory: 

• OJMB (16bit wide). 1MB or 2MB memory addressing 32bit wide (as in 5428) 

• 7 or 2 256Kxl6 one bank or 4 256Kxl6 two banks (2 CAS symetric, 2 WE asymetric) 
(as in 5428) 

• maximum memory clock frequency: 50MHz/3V, 65MHi/4.5V Priority: C 

1 1. Flat Panel Support: (Priority: A} 

• Color TFT (24bit, 18bit, 12bit,9bit) 

• Color Dual Scan and Single Scan STN (1 6 and 8 bit, including dual clock panels) 



• Monochrome TFT (8bii), 

• Monochrome Dual Scan STN (8bit), 

• Monochrome Single Scan (4 and 8bit) suppon 
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• Simulscan with all Fast Panels (6.3MHz or equivalent) with 32bit wide memory. 
No simulscan with 16bit wide memory with dual scan color panels. 

No simulscan for 3MHz monochrome dual scan panels. 

• 640x480 single and dual scan support (PriorityrA) 

• 800x600 TFT and no single and dual mono and color STN panel support (Priority: C) 

• 1 024x768 TFT and no single and dual scan STN panel support . (Priority: D ) 



12. Display Features 

• High quality monochrome and color shading, at least as good as 6440. Priority: A 

• Shading option for fast panels. Priority: B 

• Up to 8, 64x64 Hardware Icons independently mapped color+transpareni back- 
ground. Priority: C 

• Whisper Cross-Talk Reduction (If panels will be available in the timeframe and if we 
can accomodate it with the shading algorithm). Priority: C 

• "Office Productivity Booster Dual Display** 640x480 (panel) & 640x480 (CRT) 4 or 
8b/pel or 640x480 (panel) & 1024x768 (CRT) 4 or 8b/pel Priority: E 

• Vertical Expansion in text and graphics (as in 6235 or 6440) 

• Automatic Centering if not expanded (as in 6235) 

• Grey 'Shades Maping options ?? Is this needed ? Priority: D 

• Text Contrast Enhancement options, (as in 6235 or 6440) 

• In/dng Plane ?? Priority: D 

•180 and 90 degree image rotation ? ? Priority: D 

• 12 and Jddots wide font support ?? Priority: D 

• hiw offset on hlw cursor ?? Priority: D 

13. Resolutions Supported: 

• the same as 5428 at 5V (4.5Vmin) 

• up-to45MHzdotclk (1024x768, 60Hz interlaced) at 3.3V 



U.Power Management 

• Mixed 3.3V and 5V operation: memory, host and flat panel independent VDD 

• Green-PC spec support. Priority: B P'^J'^^ Confidential 

Business Information 

• Stand-by Mode with internal stand-by timer (as in 6235) 

CL 146369 
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Suspend Mode I/O or pin in all modes (LCD, CRT,Simulscan) 

Light Sleep ?? • better not for this chip as it requires too much h/w. Priority: F 

Panel Power Sequencing: automatic or under I/O control (as in 6235) 

Reduced Active Power in Panel Only Operadon: < 60nL\mp (5>3.3V Priority:A 

Reduced Suspend Current: < 0.5mAmp. Priority: A 

2.1 Inputs from the Nordic-IM Features Meeting of 09/10/93 

- 24bit DAC if not too expensive (VAR) 

- mclk @5V max 65MHz, @3V max 50MHz 

- vclk and fpvdclk @5V max 85MH2, @3V max 65MH2 
* panels: 

- TFT 1280x1024? ##, lkx768 ##, 800x600 640x480 

24bii, 1 8bit, 1 2bit, 9bit color, 6bit mono 
NEC analog nutpm-> ## 

• STN 800x600 dual scan color, 640x480 ds color 16bit 

640x480 ss color 8bit 
640x480 mono bit 8bit and 4bit 

- horiz ## and vertical centering 

- normal 9dot font in 800x600 text ## 

- simulscan for 800x600 and lkx768 panels ## (need to run all modes at 
800x600 or 1024x768 rezoludons -> option to clock panel till h&v Blank ) 

- support for two alternate fonts 10x24 for 800x600 (10x18 actual 
with spacing) and 12x25 for lkx768 ## difficult !! 

- h&v text expansion in 800x600 and lkx768 naneU m -> 

- color text enhancement ## : bright white instead of white 

• on chip cross-talk reduction ? - any improvement ? 

- shading look-up tables ## ? - only if not too large 

- NO Whisper support even on the bus side • out ! 

- NO one 256Kxl6 DRAM support - out ! 

' h/w icon support: with h/w cursor, up to 4 simultaneously. Horizontal position 
controlled in increments of 64 pixels. 

Icon attributes: off/on, 4 colors/3colors + transparent, no_blink/blink. (simple/dou- 
ble). 

H/W cursor goes over the h/w icon (visually). Uses independenly mapped color in 
RAMDAC RAM. Stan at scan-hne 64. 

- PC98 integrarinn'> ## - to be negotiated 

- reserve pins for SDRAM-s and CDRAM-s ## 

- NO true dual displayl Cirrus Coafidential 

Business Information 

12 Inputs from Compaq 09/10/93 

- 50MHz 486DX bus 146370 

- 75Hz refresh rate 

- need one 256Kxl6 support with Audio and some video for Contura . build one 
motherboard for Contura and LT Lite, Two DRAM*s only on LT Lite. 
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- think that 8KB/buffer of audio buffer is not enough 

- want to use Analog Devices for Audio 

- No clear winner on conpression. They are watching. Need Indeo driver. 

- Play-back zoom is required. At least pixel replication. 

• Very interested in Compressed Live Video. WAnt to talk more. 

- need h/w icon 64x64 with 3col+iransparency or 4 color, with pixel replication to 
128x128. 

I 

23 Inputs from AST 09/15/93 

- They prefer horizontal icon 

2.4 New Features as of 10/04/93 

- 4bit/pel packed support for Windows Chicago 

- 8bit/pel video out to the Feanirc Connector for conversion to NTSC-out 
with Nordic running 640x480 interlaced mode. 

Another idea was to use some of the panel outputs in this case and extend 
the data out to 16bits. 

- The h/w icon can be horizontal or vertical using the Motion Video Window as implemen- 
tation vechicle -> is it worth? 

• IBM Raleigh asked for 12 and 16dots wide fonts for h/w assisted Kanji. 10/04/93 

- IBM Raleigh asked for 8bit monochrome TFT panel support 10/04/93 

3.0 Important Additions to 5428 Data Base 

1. 32 bit CPU Data bus in VESA VL bus support 

2. PCI bus support 

3. Mono and color, STN and TFT Flat Panel support (incl. hfb), 

4. Live video in a true color window with Windows running in planar VGA mode, 
without a video port (using PCMCIA standard bus and Sasha»s decompression 
technique). 

5. CINE PAK decompression accelleration 

6. Audio Port support for CS4215 

7. Power Management: panel power sequencing, stand-by mode, suspend mode 

8. Mixed Voltage, 3 JV operation and low active/suspend/sundby power 

9. h/w icon support, with a h/w cursor support 

10. BLT performance improvements: Memory Mapped BLT I/O, patternning, 16 
byte Source buffer 

Cirrus Confidentia] 
Business Information 
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[I. [dual display 1024x768 on CRT with 640x480 on LCD, using the same RAMDAC ] - 
if decided to do now 



4.0 Detailed List of Features 

4.1 WAS: On tlie Cross Talk Reduction Technique •> not in >1M 

This pan was deleted from Nordic- IM spec starting rev. 3.8 (09/1 1/93). 



4.2 Green PC Spec Support 

(Based on VESA DPMS Proposal l.Op rev. 0.53p) 

This specification rcffcrcs to CRT Monitor power management. Additionally, Nordic will 



TABLE 1. Display Power Management Summary 



SUU 


HSYNC 


VSYNC 


Video 
RGB 


Compliance 


Power 
Savings 


Recovery 
Time 


CRT On 


Pulsese 


Puisees 


Active 


MandacOTv. 


None 


NA 


CRT 
Stand-by 


No Pulses 


Pulses 


Blanked 


Optional 


Minimal 


Shon 


CRT Sus- 
pend 


Pulses 


No Pulses 


Blanked 


Mandatory 


Substantia] 


Longer 


CRT Off 


No Pulses 


No Pulses 


Blanked 


Mandatory 


Majumum 


System 
Dependednt 



control DAG power consumption. These power management CRT Monitor states arc not 
necessarily related to the graphics controller power management states. 



We'll define 2 bits - GRE[2:1] (the sanne as Alpine) that control HSYNC, VSYNC and 
DAC Power Off signal (or Blankn to the DAC). 
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TABLE 2. GR£(2: II Effect 



GRE[2:1| 


CRT 
Suu 


Vsync 


Hsync 


DAC Power 


Nordic 
Power 

Managemeot 
Stau 


U 




pulsing 


pulsing 


on 


active 


1 


Stand-by 


pulsing 


static at 
MISC[6] inac- 
tive level 


off 


active 


2 


Suspend 


static at 
KflSCf?] inac- 
tive level 


pulsing 


off 


active or 
stand-by 


3 


Off 


staDcat 
MISCtT] inac- 
tive level 


statical 
MISC[61 inac- 
tive level 


off 


active, stand- 
by or suspend 



If Nordic is in its own Suspend mode, the BIOS should propam GRE[2:1]=3 to put the 
monitor (if any ) in the Off state. 

If Nordic is in its own Stand-by mode, CRT Suspend mode should be forced bt the h/w, as 
stand-by is a timer driven mode and no s/w gets to play. 

If Nordic is in LCD only, the BIOS should set GRE[2;I) to 3 to power off the CRT that 
may be connected to the notebook computer. 

If CRT only mode and CRT is in sund-by or suspend, the BIOS may reduce the video 
clock and even memory clock frequencies after saving the current values. 

Except for the above restrictions, CRT Power Management modes arc not related to Nor- 
dic power management modes: they can be independcndy programmed. 

If MISC bit is programmed for positive polarity, the SYNC signal will be stopped L, oth- 
erwise it will be stopped H. 

4.3 Play-back Decompression Accelleration 

(applicable to Cinepak as well as other compression 
standards) - old, kept here only for reference 



4.3.0 The prr^fylf yy^ Cirrus Confidential 
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a) When playback data is compressed on a CD ROM, it is encoded in 24bit/pel YUV with 
cronriinance sub-sampling. Due to CDROM reduced bandwidth the display window is 
160x120 or 320x240. If this compressed data is decompressed at full pixel depth, it 
should be displayed as 24bit/pel RGB window under MS Windows. As the play-back data 
is sent to the graphics controller from the CPU bus, it has to be placed in Video Memory in 
320KB. 

A standard VGA controller or even GD5428 are able to display the 24bit/pel play-back 
window only if MS Windows is run in 24bit/pel mode (for instance 1024x768 24bit/pel or 
640x480 24bit/pcl) by the driver. Under these conditions, the CPU will have to write the 
un-compressed 24bit/pel play-back data in the appropriate position in Video Memory, 
contigouus to the entire displayed data. 

So, in order to display 24bit/pel in a play-back window, GD5428 needs the driver to run 
24bit/pel at the maximum display resolution. 

But, in order to run 640x480 at 24bit/pel we need 921.6KB of Video Memory and in order 
to run 1024x768 24bit/pel we need 2359.296KB of video memory. (Please note that 2M of 
memory has 2097. 1 52KB). 

Also, when runrung windows in 24bit/pcl mode the performance will decrease 3 or 4 dmcs 
relative to 8bit/pel mode, especially when using DRAM as Video Memory. 

b) When running through MS Windows GDI, the driver can play-back data at 15f^ps or less 
(with a 486 33MH2). It is desirable to play-back data at 30fps. 

This can be accomplished today only if the driver docs not go through GDI. 

c) If a picyure was stored on CDROM at low resolution (160x120 or 320x240) and it 

needs to be "zoomed", it has to be interpolated both horizontally and verdcally for good 

picture quality. Vertical interpolation is expensive in h/w. Cirrus ConfideDtial 

Business Information 

4,3,1 The Generic Solution > old, here for reference only 

Today's Windows Accellerators run MS Windows, including the play-back window with 
the same pixel depth (8bit/pel). normally going through the RAMDAC. but using a split 
palette approach with 16 colors reserved for MS Windows and 240 colors reserved for the 
play-back window. The Cinepak driver writes data in video memory in 3:3:2 RGB format 

(8bits/pel) which is created by the driver. Because of the s/w overhead involved in decom- 
pression as well as the GDI overhead, it is hard to go beyond 320x240 clips at 15fps, 
though the display quality is much lower than what Cinepak could achieve (240 colors 
versus 1 6 million colors ). 

To run Cinepak with 24pit/pel resolution, today's graphics controllers would require to run 
MS Windows in 24bit/pel mode, requiring almost 1MB in 640x480 and over 2MB-S in 
1024x768 modes. 
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A graphics controller that could nin MS Windows in 8 or 16bit/pcl mode while 
displaying only the play-back window in 24bit/pcl mode would increase significantly pic- 
ture quality without degrading too much MS Windows performance with play-back, 
would reduce significantly the amount of Video Memory required for the same picture 
quality and would allow a higher frame rate for the play-back. 

Further, if the play-back data is stored in Video Memory in a semi-compressed format that 
requires less than 24bit/pel this would further decrease the Video Memory requirements 
and it may even reduce the video memory band-width requirements. 

When zooming the play-back window from 160x120 to 320x240 or higher it is important 
to interpolate. Verdcai interpolation can be done in s/w but with a relatively large over- 
head. It may be possible to do vertical intcrpoladon on key frames, but there is no practical 
way of doing vertical interpolation on inter-frames either in s/w or with h/w assist on the 
CPU write side of the graphics controUer. If s/w driven vertical interpolation on key 
frames is not a solution, then verical interpolation can be only achivcd in h/w on the CRT 
read side and this requires either one or two 16bit/pel line buffers or a big penalty on video 
memory bandwidth (the equivalent of reading 32 or 48bits/pel). 

Horizontal interpolation can be done before play-back data is displayed, without s/w help. 

Please note that there are multiple ways to solve the play-back problems. In Nordic- IM 
we'll try to strike a ballance between the complexity of the h/w solution and the quality of 
the play-back image. 

To a large extent, the solution adopted in Nordic- IM will be generic, not tied to Cincpak, 
though it will be first applied to Cinepak. 



4.3.2 Nordic- IM old Play-back Accelleration Solution -> canned, kept here for reference 

a) Nordic-lM will run Cinepak at 1:1 scale exacdy the same way as today's graphics con- 
troUers: in 8bit/pcl MS Windows with 8bit/pel (3:3:2 RGB) play-back window. 

b) Nordic-lM will run 1:2 scale (zoom) in 8bit/pel 1024x768 MS Wmdows with 24bit/pel 
(8:8:8 RGB) pixel depth in the play-back window, horizontally interpolated and vertically 
doubled. Play-back data will be stored in video memory as 16bii/pel (YO UOl Yl UOI ). 

c) Nordic-lM will run at 1:1 scale in 16bit/pel 1024x768 MS Wmdows with 24bit/pel pixel 
depth in the play-back window. Play-back data will be stored in video memory as 16bit/ 
pel (YO UOl Yl UOl ). This mode is good for programs that store dau in 320x240 format 

Because today large play-back windows look bad, while small ones look OK, this solution 
will improve picture quality to a large extent. 

Cirrus CoofideDtia! 
Business iDformatloo 
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Concerns: 

Many play-back programs today don't even have a zoom option. To this extent, mode "b" 
may not be needed. 

Mode c could be implemented today with 16bit/pel RGB (555) in s/w and the only 
improvement we provide is 24bit/pel capability and h/w color conversion (some level of 
acccUcration). So mode "c" may not be needed as a special h/w. 

If this is the case, maybe we do not need to do anything in h/w for Cinepak ! 

One idea: should we run 24bit/pel MS windows stored in 4:2:2 (YO UOl Yl UOl ) for- 
mat? This wiU allow us to run 24bit/pcl MS Windows and use 16bit/pel memory space 
with no loss of quality. The windows driver could compress the data and the h/w could 
decompress it 



4.4 Nordic-IM Motion Video Architecture 

4.4.0 The Problems to Solve & Generic Solutions 

Nordic- IM is supposed to suppon CDROM play-back and live-video under Microsoft s 
Video for Windows. With all of today ^s VGA Compatible Graphics Controllers, the play- 
back picture pixel depth has to be the same as the surrownding MS Windows pixel depth. 
In other words, we have to run MS Windows in a 24bit/pel mode in order to display 24bit/ 
pel in the play-back window. 

The only way we can run today live video is from a Video Pon (= Feature Connector). In 
this case wc*ll use an overlay or a color key to define the live video window. 
Due to CDROM player, s/w interface complexity, CPU bus and Video Memory limita- 
tions, only small clips at 15fps or less can be playd-back today. So today we need a lot of 
Video Memory to run small clips in slow motion at low rezolution. Nordic- 1 M will try to 
use less Video Memory, increase the clips size, their resolution and speed. 

Nordic«lM is supposed to support: 

- accellerated play-back for all popular CDROM compression standards, especially 
Cinepak and Indeo 

- live video from a PCMCIA card in a system with a standard PCMCIA host adapter, 
for a "Multimedia- Ready Notebook Computer" 

- live video from a Feature Connector, preferably VESA Advanced Feature Connector 
compatible, for a Multimedia Notebook Computer with direct NTSC input (full mother- 
board solution). 

What will NorriiclM hrin, .n .h> ViH^ n.o.,. SZ^lnSt^Sn 
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A. Nordic- IM will break the dependency between the pixel depth of MS Windows and the 
pixel depth of the live-video / play-back window. By doing so, Nordic- IM will be able to 
run 24bit/pel LV/PB while running MS Windows in 8bit/pel or 4bit/pel (even planar). 
This will lead to high quality hvc-video and play-back, while minimizing Video Memory 
requirements. 

B. Nordic- 1 M will further reduce Video Memory requirements as well as Video Memory 
Bandwidth requirements by storing data in compressed form: 4:2:2 YUV ( 16bit/pel), 4:1:1 
YUV (i2bit/pcl) or Sashapak YUV (2.6bit/pcl) 

C. Nordic- IM wiU define one architecture and work- frame to run both play-back and live- 
video in a unitary way for both s/w and h/w, 

D. Nordic- 1 M will support up to two acdve LV/PB windows at the same time. 

E. By providing h/w YIJV->RGB convenion and 1:2 zoom Nordic- IM will accelleratc 
playback for most standards, but mosdy for standards that allow us access to their decom- 
pressor like Cinepack (for whose decompressor we have a licence). 

Nordic- IM will not provide Cinepak specific accellcration (custom BLT). 

On the Live Video from Feature ronni>rtnr (or Vid^ Pnrt^ 
Due to pin-out limitadons, the VAFC implemcntauon has to be limittcd to 8 pins of data 
requiring external muxing of 16bit data to Nordic. Further, the VAFC solution will be 
restricted to 5428 type support: overlay and color key (no memory video port). The only 
additions to the 5428 support will be the internal YUV-> RGB converter able to accept 
sequential 4:2:2 YUV (16bit/pel in avarage: Y0»U,Y1,V) and display it as a 24bit/pel RGB 
in the overlay/coior-kcy window. We may also suppon horizontal 1:2 zoom with avarag- 
ing. Nordic- 1 M will be back-wards compatible to 5428 and it will suppon also 16bit 5-5- 
5 RGB Sierra and 5-6-5 RGB XGA pixel formats. As in 5428, live video from the Feature 
Connector can be executed only from mode 5F (640x480 256 colors). 

In the following we will refer mosdy to the other two modes of openation: play-back and 
live video from a PCMCL\ card, which we*ll call compressed live video, because due lo 
PCMCIA bus bandwidth limitations, we assume that video data received by Nordic is 
compressed with Sashapak (see Sashapak deiailes further in this spec). Please note that 
due to its huge advantages, it makes sense to use Sashapak as a mother-board solution too. 
The main reason we continue to support the Feature Connector based live video is the 
availability of drivers for 5428 which will give Nordic an early stan in the live video 
arena. 

Video Memory Banrf.wirifh ron^^tramu 

Please note that, even with a 32bit wide Video Memory, there are severe memory band- 
width limitations when running 16bit/pel and 24bit/pel graphics modes. 

Assumming that Nordic- 1 M does 8 CRT fetches in a row and 1 CPU cycle, for a CRT or 
TFT panel, here are the minimum frequency requirements for memory clock frequency at 
different rczolutions and pixel depths: 
24bityngl- 

R+7P+R=12m+14m=26m with I CPU cycle per CRT FIFO fill fetches data for 

32B/3B=10pixels ^.^^^^ Confidential 

7: 7 TTTZ '. ~ Business Information 
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R+7P = 6m+14m = 20ni with no CPU cycle during non-display time 
min mclk frcq = 65MH2 / 50MHz @ 640x480 -> Nordic- IM upper limit at 5V CVDD 
= 104MHz / 80MHz @ 800x600 -> too high 
= 169MHz / 133MHz @ 1024x768 60Hz •> too high 

16bit/pel: 

R+7P+R=12m+14m=26m / R+7P = 20m fetches data for 32B/2B=16pixcls 
min mclk frcq = 40.6MHz / 36MHz @ 640x480 -> OK even at 3V 

= 65MH2 / 50MHz @ 800x600 -> Nordic- 1 M upper limit at 5 V CVDD 

= 105MHz / 83MHz @ 1024x768 60Hz -> too high 

12bit/Del: 

R+7P+R= 1 2m+ 1 4m=26m / R+7P=20m fetches data for 32B/1 .53=2 1 pixels 

min mclk freq = 30.9MHz / 23MHz @ 640x480 -> OK even at 3 V 

= 49.5MHz / 380MH2 @ 800x600 -> OK even at 3 V 
= 80.4MHz / 64MHz @ 1024x768 60Hz -> too high 

R+7P+R=l2m+14m=26m fetches data for 32B/lB=32pixels 
min mclk frcq = 20.3MHz @ 640x480 -> OK even at 3V 

= 40.6MH2 @ 800x600 ->0Kevenat3V 

= 52.8MH2 @ 1024x768 60Hz -> OK at 5V 

We may conclurig that Nordic- IM will be able to run 24bit/pel only at 640x480 rezolu- 
tion, 16bit/pel up to 800x600, 12bit/pei up to 800x600 and 8bit/pcl up to 1024x768 rezolu- 
don. These results apply only to CRT or TFT and single scan STN panels. 
Please note that for dual scan STN panels the memory requirements increase significantly. 

These severe memory bandwidth limitations lead us to attempt to minimize video memory 
traffic. If we store Cinepak daU in 4:2:2, with an avarage of I6bit/pei, independent of 
Cincpak window size, Nordic- IM will not be able to run Cinepak above 800x600. 
Any attempt to execute vertical zoom with interpolation, even with two points interpola- 
tion will further aggravate this memory band-width bottieneck. The next step should be 
lOOMHz SDRAM-s with a large CRT FIFO (32x32) or 64bit wide memory data bus. 
These considerations apply to any playback compression standard that stores data in 
video-memory as 16bit/pel in avarage. The key to a successful compression standard 
would be one that does decompresssion on the CRT memory read and stores data in mem- 
ory as 8bit/pel or less, in avarage. 

As we store live video at 2.6bit/pel and fetch it as if it was 8bit/pel with Sashapak« 
Nordic-IM should be able to run live video even at 1024x768. 

If we defined a new CDROM play-back standard based on Sashapak. then we could run 
even 1024x768 with 24bit/pel accuracy and keep it memory as an 8bit/pel. Keith and 
Ken are actually working on it, with Sasha's help. 

Cirrus Confidential 

4.4.1 On Sashapak Business laformation 

Sashapak is a highly assymetric, lossy "Block Truncation" compression algorithm opti- 
mized for visually equivalent image processing. 

Data is proccesscd as Y.U.V one byte each. U and V are sub-sampled, characterizing one 8 
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by 8 pixel array, while Y is characterizing a 4x4 pixel aray. Actually one of two values is 
assigned to each pixel inside the 4x4 (for Y) and 8x8 (for U and V). 
At compression time, the compression chip determines a threshold and two values U&L 
for each group of sixteen (4x4) pixels. This way all pixels above threshold will be 
assigned the value U, all pixels below threshold will be assigned the value L. 



31 
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Yl 


Y2 


Y3 



u,v 



YO 
Yl i 
Y2 
Y3 



Ibyte Ibyte 



U 



U 



2bytes 
BITMAP 



BITMAP 



U 



BITMAP 



U 



BITMAP 



64pixels are described by it 

6x4B=24B=192bits 

=> 3bit/pel 

Using 6bitsforU&L V 
the compression will be 
16bit/pel. 



U 



BITMAP 



U 



BITMAP 



At decompression, the bitmap will control a mux between the U and L values. This way 
the decompression is straightforward. 

The main drawback of this approach is that a BITMAP contains Y data from 4 scan lines 
and U,V data from 8 scan lines. When data is read from memory to be displayed only data 
from one scan line is used. Similarly the U/L values apply to several scan-lines and the 
same value will be read in each scan line. The same data will be read again and again in 
each scan line raising the actual memory bandwidth requirements to an equivalent of 
16bit/pel map. 

In order to overcome this problem and reduce memory bandwidth requirements. Sasha 
proposed a scan line oriented, segregated mode of data organization. This would 
require the Sashapak compression chip to write compressed data in a specific way puting 
the strain on the compresion chip address generator. The basic principles of the new orga- 
nizations are: 

1. Data is organised in the MV Window in chunks of 32 sequential pixels. 

a) For 8bit U/L resolution, as one Y covers 4 pixels. 8 U/L sequential values are needed, 
16bits each -> 8xl6/32=4W (8xl2/32=3W for 6bit res. U/L) (where W is a 32bit word). 

b) U and V U/L data is packed together in the same word (16bits for U U/L and 16 bits for 
V U/L -> total 32bits=l W) and as one pair of U and V applies to Spixels, 4 such values 
are needed for 32 scquendal pixels •> 4x32=:4W. (4x1 2x2/32=3 W for 6bit res. U/L) 

c) The mask data is also scan-line oriented: all 32bits of Y mask of sequential 32pixels are 
placed in one 32bit word and due to sub-sampling on U and V, all 32bits of U and V mask 
of sequential 32pixels are placed in one 32bit word. So in 2W data for 32 sequential pixels 
on one scan line is packed. •> 2W (the same for 6bit resolution for U/L) 

d) For 640x480 window size, even at 8bit U/L resolution, data for 8 scan-lines fits in one 
DRAM page (symetric DRAM-s assumed): 320WY+80WU+80WV=480W < 512W page 



Nordic-IM Design Specification rev3.9 October 20. 1993 



Cirrus Conndential 
Business Information. 



14 



CL 146379 



Cimis Logic. Inc. Confidential [nformadon 



SLAs 



4gOW for one 8x640 pixels block fits in one page ^ 

SBit per U/L 
resolution. 



U/L for Y 


U/L for U,V 


Y bitmaps 


UV bitmaps 


i 



* n*MVW-Offset 160W SLA+AOh gQW SLA+FOh 160W SLA+I90h 80W ^aia Grouped 
Where Si is scan-line number i inside the block SO S 1 S2 ... S7 SO.l .... S6.7 per Scan Lines 



f) The key to memory bandwidth optimization is the fact the the compression chip will 
organize data sequentially over 32 pixels instead of 8. This will be done for the mask bits 
which will be organized sequennally by scan line and for the U/L data. This way a 32bit 
word of Mask data contains only informadon for the cunent scan line and no extra mem- 
ory fetches are required. The main reason we segregate U/L for Y and U/V is the fact that 
we want to use 6bit U/L. In this case it is easier to identify the proper U/L info chained 
within 32bit words if the words are sequential and we have a fix relationship between 
their address and the 6bit U/L quantities. 

g) If we calculate now the amount of data we need to fetch to display 32 sequential pixels: 
• for 8bit per U/L: 4W (YU/L) + 4W (UV U/L) + 1 W (YM) + 1 W (UVM)=10W=40B 

--> 40B/32pixels»320bit/32pixeIs=l Obit/pel to fetch from memorv 

- for 6bit per U/L: 3W (YU/L) + 3W (UV U/L) + 1 W (YM) + 1 W (UVM)= 8W=32B ' 

"> 32B/32pixcls = 8bit/pixel 
This is a very good data fetch ratio, much better than the 16bit/pel we'd get without the 
optimization. 

g) When reading data from the Motion Video Window the controller will generate the fol- 
lowing sequence of addresses, all of them in the same DRAM page (8bii per U/L): 

- fetch the YU/L for the first 32 pixels on scan-line n at addresses: 
MVW.S tan+n*M VW_offset, + 1 , +2, +3 

- fetch the UV U/L for the first 32 pixels on scan-line n at address: 
MVW_Stan+n*MVW_offset+AOh, +1, +2, +3 

- fetch the Y BitMap for the first 32 pixels on scan-line n at address: 
MVW_Start+n*MVW_offset+FOh 

- fetch the UV BitMap for the first 32 pixels on scan-line n at address: 
M VW.S tan+n*M VW_offset+ 1 90h 

- fetch the YU/L for the first 32 pixels on scan-line n at addresses: 
MVW_Sian+n*MVW_offset+4, +5, +6, +7 

- fetch the UV U/L for the first 32 pixels on scan-line n at address: 
MVW_Sian+n*MVW offsei+AOh+4. +5, +6, +7 ^''"''us Confidential 

- fetch the Y BitMap for the first 32 pixels on scan-line n at address: Information 
MVW_Stan+n*MVW_offsei+FOh+l 

- fetch the UV BitMap for the first 32 pixels on scan-line n at address: 
MVW_Stan+n*M VW^offset+ 1 90h+ 1 

- now the MVW FIFO is full. 

■ chunks of ten 32bit words will be proccessed for every 32pixels displayed 

- the MVW FIFO gets empty after the first 10 words being read for decompression and 
display. 

Please note that all data for every 8 scanlines starting from the top of the MVW is in the 
same DRAM page. 

Because we have to fetch the MVW Data before we stan displaying it. and because at that 
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time the CRT FIFO docs not empty as fast as it is needed (unless MS Windows is running 
at the same pixel depth as the MV Window), it is necessary lo have a separate FIFO for the 
MVW or at least half the FIFO (at least lOW for 8bii per U/L and at least 8W for 6bits per 
U/L). 

h) When wc run 6bit per U/L, because the Video Memory band- width requirements are as 
if wc were running 8bit/pcl, wc could do vertical zoom with avaraging. But there should 
not be a need for zoom with Live Video because there is enough CPU and memory band- 
width to run 640x480 windows even when MS Windows is run as 1024x768 4 or 8bit/pcl. 

Conclusion: With Sashapak we can get data organized in memory such that the memory 
bandwidth is as for 1 Obit/pel (8bit U/L) or 8bit/pcl (6bit U/L) pixel depth. The actual 
memory area will be close to 3bit/pel or 2.6bit/pel depending on the resolution of U/L val- 
ues - 8 or 6bits per value. 

Please note that the memory area will be slightly larger due to the fact that we use only 
480 words in a page of 512. 

4.4.2 YUV to RGB Conversion Algorithm 

The ideal YUV to RGB transformation is: 

R=Y+ 1.37 V 

B=Y+1.73U 

G=Y.0.699V-0.336U 

After defining an objective way of measuring color error, Sasha came up with the follow- 
ing Conversion algorithm: 
R=Y+1.375V=Y+1 3/8 V 
B=Y+1.75U=Y+1 3/4U 
G=Y-0.375U.0.75V= Y.(3/8U+3/4V). 

This algorithm can be implemented with 8 9bit adders. 

4.4.2 Motion Video Architecture Functional Blocks 

Instead of treating play-back and live- video as two separate modules, we'll isolate several 
generic functions to be used by both: 

Cirrus Confidential 

- Display Window Generation Block: Information 
allows s/w to define one or two piay-back or live video window(s). 
The MV Window is defined in 4bit/pel equivalent CRT Addresses: 

- MVW Stan Address (19bit) 

- MVW Width (max 640pixcls => 80 addresses) -> CRT address after MVW on 
each scan line. 

- The number of memory cycles to be executed at MVW pixel depth on each MVW 

scan-line (max 320 cycles for I6bit/pel storage at 32bit/pel pixel depth) -> 
scan line end. 

- MVW OFFSET to the start of the next MVW Scan Line (19bit) 

- MVW End Address (19bit) or MVW number of scan-lines (9 bits). 
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Scan-linc doubling for "zoom" should be taken into account when designing DWG. 

• Off-screen MV Memory Addressing and Access Control. This includes data type tag 
generation based on MV memory Address and the circuitry placing the tags in the CRT- 
FIFO. This also includes the MV prefetch cache that makes sure that there is enough 
prefetched MV data before starting and MV scan line display. This block has provisions 
for scan line replication by repeating the MV address generated on the previous scan line 
of the MV window (only). 

- One tag bit is generated based on CRT Address and is 1 if the data in the CRT FIFO and 
the pre-fcich buffer is from the MVW, other-wise is 0. This tag bit, called the steering bit 
will be delayed through the entire data path and end up controlling the final video data 
mux just before the DAC 

- MV Data Path and CRT-FIFO Control. This is area wise the largest piece. It consists of a 
new 16bit wide data-path with the same delay as the VGA data path, that takes MV data 
from the MV prefetch cache and the CRT FIFO, treats it appropriately depending on the 
MV data format encoded in the MV ugs and converts it to 24 bit YUV first and 24bit 
RGB second. Horizontal zoom with avaraging (or maybe 5 levels of interpolation) is in 
this block too. 



• Prc-fetch MVW Buffer - is needed in order to prc-fetch scan line data for the Modon 

Video Window every scan-line. Because the MS Windows pixel depth and MVW pixel 

depth don't match, it is necessary to fill in a separate buffer every 

MVW scan line before the CRT- Address Counter reaches the window boundary. 

The buffer will be filled first during vertical non-display time and later after each VMW 

scan-line display. For Sashapak this buffer has to store data for 32pixels 

(10x32bit for 8bit per U/L or 8x32bit for 6bit per U/L). 

This function can be implemented as a dinamic size modification in of the CRT-FIFO. If 
the CRT- FIFO has 24 stages instead of 16 but only 16 stages are used before the MVW but 
it is switched to 24 when MVW fetches start there will be 8 more stages to fill at that time 
ensuring more prefetched data in the CRT-FIFO at the beginning of each MVW scan-line. 

- Steering logic decode the tags comnung out of the special addition to the CRT-FIFO and 
the pre-fetch buffer and controls the decompression, formatting and serialization. 

(they tell the formatter what data is Y, U or V). 

- While switching to display the MVW the CRT Address counter continues to count at the 
pace set by the graphics mode outside the MVW (4 or 8 bit per pixel normally). The 
counter contents is compared with the MVW boundaries to detect the end of the MVW. 

- What about the video scrializer load and the CRT FIFO read signal? What hapens to 
them when in VMW? They are one signal today 

WHEN the data path switched to display VMW data, what hapens with the VGA Video 
Data Path is don*t care as we do not display that data, except for the h/w cursor anf the h/ 
w icon that do not go through the standard VGA serializer. So we'll probably stop the 
VGA data path untill the point h/w cursor and h/w icon are combined into it, to save 
power as we will stop the VMW data path when not in use, for the same reason. 

*; 7 TrrZ " ~ cirrus Confidential — 
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So, the Video Serializcr Load may be stopped while VMW data is displayed, but the CRT 
FIFO read will be going on, with a frequency and shape depending on the data fomiat 
loaded in the CRT FIFO for didplay. 

At the beginning of each VMW scan-line, the CRT-FIFO signal read will be applied only 
to the prc-feich buffer and not to the CRT-FIFO itself (the CRT-FIFO read pointer won't 
change). Subsequently, when the pre-fetch buffer is empty (format dependent), the CRT- 
FIFO read will be applied to the CRT-FIFO read pointer after the data the pointer is point- 
ing to was loaded into the VMW fomiattcr and serializer. 

In RGB 3:3:2 8bit/pel direct color mode CRT-FIFO read will be generated every 4 vclks. 
In standard RGB 5:5:5 or 5:6:5 16bit/pel modes CRT-FIFO read will be generated every 
two vclks. 

In YUV 4:2:2 24bit^l (YO U Yl V on one scan line) the CRT-FIFO read will be gener- 
ated also every two vclks, 

IN Sashapak 10 (for 8bit per U/L) or 8 (for 6bit per U/L) CRT-FIFO read pulses wiU be 
generated every 32 vclks. 

- The VMW Address Counter, loaded at the beginning of each VMW scan-line with a stan 
address calculated based on the Start VMW Address and the VMW Address Offset, will 
count at format dependent rate for as long as the CRT-FIFO is not full. Because the CRT- 
FIFO will be empded faster in the VMW (in general the pixel depth will be higher in the 
VMW) there will be requests for more memory cycles when displaying in the VMW. 

• If either h/w cursor or h/w icon arc on, they should be displayed even if the direct data 
path is used. In this case both video data pathes will clock and the steer tag will point to 
the VGA data path when either h/w cursor or h/w icon or both are displayed, even on top 
of a M V window. Please note that neither the h/w cursor, not the h/w icon data go through 
the CRT FIFO or the VGA Data path except for the final pixel address block and the 
RAMDAC RAM, though they have a special path in the RAM. So we could stop most 
of VGA data path (including the internal palette) but not all of it even if we arc in 16bit/pel 
mode (the new one that goes through a separate I6bit data path). 

- If we are in a 16bit/pcl mode with no h/w cursor or h/w icon, or in a 640x480 MVW 
mode filling the screen, we can stop the VGA data path to save power. 

- The off-screen MVW memory will be a fix memory array towards the end of the mem- 
ory, but before h/w cursor, h/w icon and the half frame buffer, even the color one. The start 
of the MVW memory will be fix for a memory size but it will be moving with the memory 
size: 2MB configuration will support enough memory to support: 

- one 640x480 3bit/pel window or up to two 320x240 3bit/pel (Sashapak) -> 32KW 

- one 640x480 16bit/pel window or two 320x240 16bit/pel windows 
(153.6KW=614.4kB out of 256KW or 512KW avaUable depending on the memory con- 
figuration) . 

- all of the above at the same rime up to a total of two windows though. 

1MB configuration will support: 

- one 640x480 3bit/pel Sashapak window or two 320x240 Sashapak windows or 

- two 320x240 16bit/pel windows. 

In general, the MVW off-screen memory stan address is fix, but it can grow into hfb mem- 
ory if there is no hfb. 

Cirrus CoDfldential 
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V/e may decide to place the start of the MVW memory array at either one of two locations 
to optimize for TFT panels versus STN color 

PLcasc note that about 56KW arc needed for 800x600 DS Color STN HFB, the h/w cur- 
sors and h/w icons while about 36KW are needed for 640x480 DS Color STN HFB and 
that 

- 640x480 4bit/pcl requires 38.4KW 

- 800x600 4bit/pel requires 60KW 

- 1024x768 4bit/pel requires 98.3KW 

- 640x480 8bit/pel requires 76.8KW 

- 800x600 8bit/pel requires 120KW 

- 1024x768 8bit/pel requires 196.608KW 

Video Motion Formats supported are: 

- 8bit RGB not going through the palette (RGB 3:3:2) 

• 16bit RGB (5:5:5 Sierra and 5:6:5 XGA) not going through the palette -> this is a 16bit/ 
pel that does not require double dotclock !! 

- 4:2:2 YUV Y0,U,Y1,V for Cinepak (or 4:1:1 if proven more useful) 

- Sashapak format (YO-ULM, Yl-ULM, Y2-ULM, Y3-ULM, U-ULM, V-ULM) 

The tags that accompany the modon video data through the CRT-FIFO mark both the data 
format and the type of data inside the format (U/L for Y or U,V or mask for Y or U V in 
Sashapak, YO, YUU or V in 4:2:2). 

Note: It may prove simpler to design a system in which the MVW is dc6ncd on the Hori- 
zontal and Vertical Counters instead of the CRT- Address. In this case, for the system lobe 
simple we should fetch both normal CRT data and MVW data on the scan-lines on which 
there is MVW data. Other-wise we have to prefetch CRT data during the window. 
The system would have two separate FIFO-s. A MVW wiU be detected during the hori- 
zontal non-display dme of the previous scan line and a MVW FIFO fill will occur. Once 
the MVW FIFO is empty, a refill will be in order. The CRT FIFO will be refilled before the 
MVW ends unless the CRT FIFO cycles continue normally during the MVW. which 
requires a lot of memory bandwidth. 
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Note: For tinung considerations MVW-Sian Address and MVW-Lasi- 
Address will be programmed as minus 1 or even minus 2 if required, to allow 
early detection of a window boundary. 
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4.5 Feature Connector Support 

Nordic- IM will suppon 5428 Feature Connector so thai it is compatible to Media Man- 
ager. 

Nordic- IM will suppon VAFC (Vesa Advanced Feanire Connector) in the 8bit VSVPC 
passthrough compadbility mode. 

The main difference beteen 5428 PC and Nordic PC is the fact that 5428 PC has one 

EDCLKn control pin controlling the direcnon of the DCLK pin, while Nordic- IM as weU 

as VAPC have a FCDCLK output pin and a FCVCLK input pin. 

Dave Keene believes that 5428 PC is VAFC compatible. To case the design, I kept 5428 

PC pin names (not VAFC pin names). 

On VAFC compatihilitv here are some comments: 

- GENCLK can be applied on XVCLK if SR22(3]=I. 

But, if SR22[3]=1 (select xdk) & SR24[71=1 (VAFC enabled), then XMCLK 
should get OSC and MCLK Synthesizer operates normally, except that the reference 
frequency comes from XMCLK instead of OSC pin* If SR22[3]=1 & SR24[7]=0, then 
MCLK comes directly from XMCLK pin and the MCLK and VCLK Synthesizers 
are powered-down !! 

- GRDY signal is similar to OVRW. 

- VRDY is similar to EVTOEO if EVIDEO is dinamically switched as a valid data in sig- 
nal. 

- EGENn is not needed if we configure Nordic- IM in the right configuration with 
SR22[3] (XCLKPU) and SR24[7] (VAFCPU), 

- As VAFC maximum FCVCXK frequency is 37.5MH2, VAFC supports a mode in which 
data is sent at 37.5MH2 to the DAC and it each pixel will be displayed twice if the chip is 
running at 75MHz pixel clock. This allows only 8bit/pcl data to be displayed. To display 
16bit/pel data we should use both phases of the FCVCLK and pack the data into one pixel. 
I think that this is already done in 5428, if not Man-Shek and Pong-Jim are modifiying the 
5429 RAMDAC to suppon this mode •> we need to support it too. 

- VAFC requires FCDCLK to be switchabie under s/w control beteen Ix and l/2x the 
pixel clock. If we took this out of Nordic- IM data base, we should put it back, but the 
divide by two should affect only FCDCLK going out of the chip. 

Check VESA VAFC Proposal l.Op rev. 0.31 07/15/93 for VAFC timing info. 

Cirrus Confidential 

NordiclM FC Pin< Ft mrtinnal no;scription Business Information 

Most of this is from 542X Data Sheet page 3-26: 

VS YNC and HSYNC TO The standard CRT pins tri-stated when PCESYNCn is L. 

Thes pins have programable polarity. 

FCBLANKn I/O BLANKn in 5428. If PCESYNCn is H, this is an output 

and it supplies the actual composite BLANKn CRTC signal. 
VAFC requires this to be the composite Display Enable 
(no borders). If this is the case, well need a bit for VAFC 
that puts DE = HDE & VDE inverted on BLANKn. 
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If FCES YNCn is L, FCBLANKn is an input and it forces 
RAMDAC RAM outputs to 0 (black), but it should force 
them black before they go to the panel. 
It seems that by connecting OVRW output to BLANKn as 
input we can display FC data in a window - this will work 
though only if OVRW, internally controls the pixel address 
mux between normal VGA data and the FC data. 
FCP[7:0] UO P[7:0] in 5428. 

If FCEVIDEOn is these pins arc outputs and 
represent the pixel address of the RAMDAC. 
IF FCEVIDEOn is L, these pins are inputs and represent 
the pixel address to the RAMDAC. 
CRl A(3:2] conaol the way the FCPt7:0) are muxed with 
the normal data. 

FCDCLK O (the actual pin is I/O) outputs V(XK or VCLK/2 if selected through s/w. 
FCESYNCn I ES YNCn in 5428. Controls HSYNC, VSYNC and FCBLANKn 

(H-> outputs, L-> HA^S YNC are tri-statcd, 

FCBLANKn is iri-stated.). 
Nordic docs not have EDCLKn input as FCDCLK and FCVCLK arc not shared. 

OVRW 0 OVRW in 5428 = Overlay Window. This active Low signal, is generated 

by the BLANKn VT and HT logic (shared) and is supposed 
to be used to create an Overlay Window in which data 
from the Feature Connector is displayed. / don't know 
why we output this signal. It should be controlling the 
MUX between the normal pixel address and the FC 
originated pixel address. 

4.6 On WavePort Architecture and Audio Driver 

Starting from Dave Kccne's WavePon Specification, Rakesh. Sasha and Vlad came-up 
with some ideas which could greatly simplify the design work for WavePort reduction the 
complexity and the number of gates of the WavcPoa Cirrus Confidential 

We'll Stan with the small issues and move towards more important issues. Business Information 

4.6.1 AUXSlandAUXS2Pin 

A. Dave proposed to share this pin with PDN (Power Down) WavcPon Pin and configure 
it as AUXS2 when using 423 IS. 

Wc noticed that 423 IS does have a PDN pin which we'd like to use to save power. 
We'll put AUXS2 on another pin. 

B, Dave proposed to have a fuUy programmable location for AUXS 1 and AUXS2 CPU 1/ 
O map with a default at 530H and 388H. This is cosUy (4 registers and fast comparators) 
and very difficult to design at required speed: will slow down address range decode for 1/0 
a lot affecting command to command parameters. 

We suggest to have a fix address for these ports: 530H and 388H. 

Two register bits (one per address) can disable the chip from answering to these I/O 



Nordic- IM Design Specification rev.3.9 October 20, 1993 23 

CL 146388 



Cimis Logic, Inc. Confidential Information 



addresses. 

If we are not sure where to place these ports, we can leave it as a metal opdon for future 
modificadon or have one more altcmarive for each, but the address should be fix for fast 
decode. 

GR58:GR5B are no longer needed if this opdon is accepted. We'll need two biu to disable 
530H and 388H address decode and eventually two other bits to select other two aiiemate 
I/O addresses. We should always decode 16 addresses: 530:53F and 388:397 (not 4 or 16). 

4.6.2 WavePort RAV Buffer Location and Size 

To simplify the h/w and reduce verification work-load , WavePort R/W Buffer Size should 
be fix: 32KB for each, enough for at least 180msec of operation -> 90msec for half buffer. 
Every 90mscc the CPU will have to fill and/or empty half Audio Buffer (write or read 
respectively). 

It is also possible to place the WavePort memory buffer in a fix memory location, common 
for both desktop and portable architectures. We could place it in Memory in the upper pan 
(in high address area), just before the h/w cursor. If the h/w cursor takes the upper 16KB 
of the memory, we could use the next 64KB for the WavePort buffer. 
Going down in memory, in Nordic we'd place the h/w icon in the next 16KB (only 4KB 
needed now... but leave some room for expansion) and the Half Frame Buffer for mono- 
chrome and color panels in the next 32KB and 96KB respectively. 

ToUl: 

96KB for CRTrTFT/SS STN panels, 
128KB for monochrome panels and 
192KB for dual scan color STN panels. 

out of 1MB or 2MB memory available. 

When the memory is expanded, all these fix components should move automatically in the 
upper side (towards the end of memory). 

This places the WavePort buffer at: 

- for 1MB of memory by 32 (256Kx32 -> 00000:3FFFF) 3B000:3EFFF 

- for 2MB of memory by 32 (512Kx32 -> 00000:7FFFF) 7B000:7EFFF 

If we adopt this solution, GR43 is not needed. SUZ^S^^^ 

4.6.3 On Host Access to WavePort Buffer 

In order to ensure independence between the Graphics s/w Driver and the Audio Driver, 
taking into account AVGA limitation of no CPU accesses during BLT operation, Dave 
proposed a separate path for WavePon Host Accesses. This involves a separate 4 stage by 
32bii write and read buffer and separate arbitration for the Audio cycles. The buffer is 
shared by WavePon read and write operations and an I/O to an extension register bit is 
needed in order to switch from a read operation to a write operation or vice-versa. 
Dave also proposed that the host address be dependent on GR6 CPU address map bits 
such that the video and audio address maps don't overlap. 

Please note that this approach prevents debug with a Hercules card when in graphics. 
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In the following an alternate scheme is proposed; 

- There is one register bit that enables WavePort memory write accesses and one register 
bit that enables WavePort memory read accesses. When one of these bits is asserted .the 
chip expects only host accesses for the WavePort: the host address will be automatically 
translated to a memory address inside the WavePort buffer. The access will be fully linear, 
32bit only, graphics mode independent (like in extended 8bit/pel). The Graphics block 
will be forced to this mode and all planes will be automatically enabled. On the Host side, 
the WavePon buffer will be placed always at AOOO:0(X)0 - AOOO:FFFF -> 64KB with 
32KB for read buffer (the upper side) and 32KB for write buffer (the lower side of this 
64KB segment). 

• The CPU Data Path is the san>e as for any other CPU cycle: no special FIFO, no special 
arbitration are required. The Audio Driver and The Graphics Driver communicate through 
interrupts: There is an interrupt for BUT completed (Dave*s idea when presented with this 
proposal) and an interrupt for Audio Buffer Full (or Audio Transfer Completed). When the 
BLT is completed, if Audio is enabled on the chip, the BLT Completed interrupt aUows 
the Audio Mver to check if there is any need to service the Audio and vice-versa. 
If possible, the Graphics driver should restrict the extent of the BUT operations to less than 
160msec or so (leaving at least 20mscc to start filling the WavePort buffer). 

- There is no on chip CPU WavePort address generation. The CPU address in the range 
AOOOO: AFFFF (incremented by 4 every cycle for DW accesses) is translated to physical 
memory address 3B(X)0:3EFFF. If host side WavePort pointers are used, the host address 
is latched and translated for comparison with the Codec pointers generated on chip. 

Adopting this scheme would greatiy simplify the extent of the design and verification 
work for WavePon: 8 weeks at least will be saved. 

Cirrus Confidential 
Business InformatioD 

4.6.4 On the Audio Driver 

Dave proposed that the Graphics Controller has h/w to compare the WavePort pointers and 
generate intcirupts. The Codec pointers are 1/0 readable by the host as well as several 
buffer status bits (Audio-IN buffer Full, Audio-In buffer half-full, Audio-Out buffer half- 
empty, Audio-Out buffer empty,...). 

Nordic- IM will suppon Dave's proposed interrupt driven interface. 
In this case the only important difference for the driver will be that it will have to generate 
the buffers address and not rely on the h/w to do this (Dave suggests that CPU will write 
and read always the same address A(XX):0 or BO(X):0 and the actual address on the host 
side is generated on the chip - we sugest to change this and let CPU generate the address). 

Because CPU has to wait untill the a BLT operation is complete and the BLT has to wait 
for Audio buffer to be full or the transfer completed, two more interrupts are needed: BLT 
operation completed and Audio transfer completed. This way the Audio Driver and the 
Video driver can communicate with each other. 
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The Read and Write CPU side pointers will be generated by latching the last read and 
write WavePort CPU address Oower 16bits only) after transiadon to physical memory 
address. Comparators on the host and codec pointers will generate Buffer Full and Buffer 
Empty signals. 

Jeff On drew our attention to the fact that the driver transfers a certain size block and 
needs an interrupt anytime half of what was placed in the Audio buffer was read by the 
Codec (the play-back buffer is half empty). To make things simple for the h/w, we propose 
to give Jeff an interrupt when the CODEC side playback buffer read pointer reached a pre- 
programmed value, value the driver programs everytime it transfers a block of a certain 
size in the playback buffer. For instance, if the driver put 2KB of data in the playback 
buffer starting from phisical address 3B000 (host address AOOOrO) and wants on interrupt 
when the first 1KB was read by the CX)DEC it should program 3B0FF in the playback 
interrupt register, as 1KB = 256 32bit words. The register will have 16bits and the driver 
will program BOFF to get an interrupt when the CODEC reads 3B0FF or 7B0FF playback 
buffer address. 

Similarly, on the record side, there will be a programablc interrupt on the CODEC side to 
be used to tell the driver when the Record buffer is half full. 
So we'll need two 16bit indexed registers for these programable interrupts. For each 
WavePon interrupt we also need a sutus bit to say that the interrupt happened, an enable 
bit to enable the particular interrupt As Dave proposed, GR4D is the Interrupt Status reg- 
ister but bits [0] and [21 will be the programable interrupts status bits. The interrupts and 
the status bits will be cleared after this register is read (automatic clear in h/w). 

We could use registers GR58:5B as high and low byte for the prDgramable interrupt 
on Record and Piay«back buffers respectively. 



The write-buffer (or Audio-Out =the one in which the CPU writes) is empty one Wave- 
Pon write cycle to memory after _ ^ . 

WRBUF-Write-Pointer = WRBUF-Rcad-Pointer+1 B^iSsSntmSn 
(this condition will activate set an empty flag). 
The write-buffer is full one WavePon write cycle to memory after 

WRBUF.Read-Pointer = WRBUF-Write-Pointer + I 
The same equations apply to the WavePon read-buffer, only this time the read-pointer is 
on the host side and the write-pointer on the Codec side. 
Shouldn't be a Audio^ut buffer fuU interrupt and a status bit for it? 

Threshold detea mechanism will require to increment host pointers, but the CPU is sup- 
posed to read this pointer and generate the proper address when going above the threshold. 
The idea of the threshold detector is that by incrementing the Audio- In read pointer every- 
time the write pintcr is incremented if the Audio data is under the threshold value, the 
delta between the pointer remains the same and the buffer docs not fiU in with sub-thresh- 
old value. This was true if the half-ftiU detection had been generated based on the delta 
between pouiters. After talking to Dave, there arc some clarifications to be made on the 
threshold detea mechanism for record: 
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For one record scsion, this is a one time event mechanism: if the threshold was passed 
once after being enabled, its effect is lost - even if the sound level goes below the thresh- 
old the record buffer read pointer works normally. The threshold will help only in the ini- 
tial stage before the first actual voice pattern is detected, but it docs not have any effect 
after the inntial triggering event - once the sound leved passed once the threshold. 

With this driver approach, GR43 and GR58:5B will not be needed. 

Five rcgistcn are saved. Twenty One register arc still needed (plus two reserved = 23). 

Another possible approach for the driver uses extensively the Verticai Interrupt: 
In this case every Vertical Interrupt, the Audio Driver reads the Codec side pointers, com- 
pares them with the Host side pointers, the driver generates based on the CPU address it 
last wrote to or read from and makes its own decisions. The driver will also check the BLT 
completed status biL 

In other words, every 18msec (@60H2) , on the Vertical Interrupt the Audio driver can 
process data from the Codec pointers, calculate based on the last address if the WavePon 
buffer is fuU or empty and decide how many more WavePon accesses to execute. As at 
least ISOmscc worth of data is in a full Wavepon Buffer, the driver has 6 opportunides to 
find out that the buffer is empty and stan filling it before half WavePort buffer is empty. 
On chip h/w is still needed to stop sending data to the Codec after sending ail data and to 
read all data from the WavePon read memory buffer on the host side. Because the CPU 
decides when the buffers are full, half fuU or empty there is no need for registers for the 
pointers on the CPU side, but the CPU address will still be latched to generate the host 
side pointers. 

The "BLT operation completed" and the "Audio transfer completed" interrupts are needed 
anyway bacuse we share the data-path for BLT and CPU cycles. 

By adopting this mechanism in the driver, no special h/w is needed to preserve pointers on 
the Host side, to compare the Host side pointers (read and write) with the Codec pointers 
and to generate interrupts and status bits. The only interrupts needed are Standard VGA 
Vertical Interrupt as a time base, BLT completed Interrupt and Audio Completed interrupt. 

We can still implement the threshold detect, 

GR44,GR45, GR48 and GR49 won't be needed. 

Nine registers are saved. Seventeen register are still needed (19 with two reserved rtgis- 
^crs). 

Cirrus Confidential 
Business Information 

Conclii^iftn 

The above proposal, if OK for the WavePon driver, would reduce significantly the amount 
of design and verification work on the WavePon. This document was written in order to 
get feed-back and reach an agreement ASAP Our goal is to have a unique s/w model for 
the WavePoa but we'd like to cut the amount of work if possible. 
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Nine registers are saved. Seventeen register are still needed (19 with two reserved regis- 
ters). 



rnndusion 

The above proposal, if OK for the WavePort driver, would reduce significantly ±t amount 
of design and verification work on the WavePort. This document was written in order to 
get feed-back and reach an agreement ASAP. Our goal is to have a unique s/w model for 
the WavePort but we*d like to cut the amount of work if possible. 



4 J Four Bit per Pel Packed Format 

To fully support Windows Chicago, Nodhc-IM should support 4bit/pel packed format 
CPU will be able to write only 8bits or more at a time. To modify only 4bits the CPU will 
do read modify write and mask four bits (bring them from CPU latches). 
The following picture shows the actual format 



Memory Data 



7 4 3 0 15 12 11 8 23 20 19 16 31 21 


}27 24 


PO 
msb tsl 


PI 
msb 1st 


P2 1 P3 1 P4 
msb Isbl msb Isa msb Isb 


P5 
msb Isb 


P6 

msb Isb 


P7 
msb Isb 



Pixel Left Pixel Right 

1 -si pel 2-nd pel 3-nlpel 4.ihpei 5-ihpcl 6-th pel 7-th pel 8-th pel 



In order to get Nordic- IM to support this mode, we need to place the VGA Video Data 
Path in 8bit per pixel mode with pixel doubling (mode 13) but disable the mechanism that 
concatenates adjaisant 4bits to make one 8bit pixel displayed twice (at a divided by two 
RAMDAC VCLK) and disable as weU dividing by two the RAMD AC VCLK. 

On the CPU side chain 4 address scrambling should be disabled and data should be 
shifted right like in extended 256 color modes. 

In nordic-regs-rev9.1st we assigned SR26[0) to enable this graphics mode. Cirrus Confidential 
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I 4.8 Robin's Ideas on High Resolution Panels for Nordic-IM 
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Nordic's objective is to be able to center and fill the screen on 800x600 panels and to cen- 
ter an 800x600 picture on 1024x768 panels. The main focus is 800x600 panel suppon 
TFT and dual scan STN. 
In TEXT there will be three options: 
- horizontal and verdcal centering with 9x16 fonts (disable 640x480 force to 8dots font) 
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4.7 Four Bit per Pel Packed Format 

To fully suppon Windows Chicago, Nodric-IM should suppon 4bit/pcl packed format. 
CPU will be able to write only Sbits or more at a time. To modify only 4biis the CPU will 
do read modify write and mask four bits (bring them from CPU latches). 
The following picture shows the actual format: 



31 29 28 24 23 20 19 16 15 12 11 



8 7 



PO 
msb !sl 



PI 
msb 1st 



P2 
msb Isb 



P3 
msb 



I P4 
Isq msb 



4 3 





P5 


P6 


P7 


Isfc 


msb Isb 


msb Isb 


msb Isb 



Pixel Left Pixel Right 



In order to get Nordic- IM to suppon this mode, we need to place the VGA Video Data 
Path in 8bit per pixel mode with pixel doubling (mode 13) but disable the mechanism that 
concatenates adjaisant 4bits to make one 8bit pixel displayed twice (at a divided by two 
RAMDAC VCXK) and disable as weU dividing by two the RAMDAC VCLK. 
In nordic-regs-rev9.1st we assigned SR26[0] to enable this graphics mode. 



I 4.8 Robin's Ideas on High Resolution Panels for Nordic-IM 

Nordic *s objective is to be able to center and fill the screen on 8(X)x6(X) panels and to cen- 
ter an 8(X)x6(X) picture on 1024x768 panels. The main focus is 8(X)x600 panel suppon 
TFT and dual scan STN. 
In TEXT there will be three options: 

- horizontal and vertical centering with 9x16 fonts (disable 640x480 force to 8dots font) 

- auto-expand the font to fill the screen 

- special font to fill the screen 

In Graphics there will be tree options: 

- horizontal and vertical centering 

- use a driver to run at maximum resolution 

- automatic expand to 800x600 (only if s/w verification shows it being OK). 

In all cases horizontal and vertical options will be decoupled (different enable bits). 

Here's a list of what needs to be done: 

a. Expand horizontal and vertical centering capability from 640x480 to 1024x768. 



b. Shadow all HA^ CRTC registers except HDE and VDE. 



Cirrus Confidential 
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The vertical registers arc shadowed now, but the horizontal registers arc not 

We need to shadow CRO, 2, 3, 4 and 5. These registers will be written by the BIOS at 

POST. 

c. Suppon lOdot character-clock and CRT-FIFO-Read / Shift/Load (Video-Serializcr 
Load). Now only 8dot and 9dot character-clocks are supported. For smooth-scrolline the 
pel-pan has to be expanded to 10 pisitions (0:9). 

d. TEXT auto-expand will be as follows: 

- horizontal: replicate the last pixel once for 9 dots wide fonts and twice for 8 dots wide 
fonts. 

- vertical: replicate all odd scan-lines 



TABLE 3. Foot ExpansaoD for DifTcreBt Panel Sizes 



FoDt-Size/Pucl-Size 


480 


600 


768 


8x14 


8x19 


10x21 


10x21 center 


8x8 with scan-In. doubling 


8x19 


10x24 


10x24 + center 


9x16 


8x19 


10x24 


10x24 + center 



Please note thai in text vertical expansion is done on the scan-line counter as well as the 
vertical display line counter, but it does not affect the vertical non-display line counter. 

e. Graphics modes expansion (to be implemented only after s/w verification) 

Graphics expansion is less important as it is assumed that important applications will run 

at maximum panel resolution with a driver. 

We*ll need to supply drivers for many applications with high res. panels !! 
Vertical expansion: 

- 3501ines -> replicate aU odd scan-lines 

- 4001ines -> replicate all odd scan-lines 

- 480 lines -> replicate every 4.th line 
Horizontal: 

- center 

- duplicate every 4-th pixel 

- duplicate every 4-th pixel with diagonal shift 

(scan-line 0 -> 1st pel, scan-line 1 -> 2nd pel, scan-line 2 -> 3rd pel, scan-line 3 -> 4th 
pel). 

5.0 Nordic-IM Pinout Specification 
208 pin package: 

System Interface (r^Ur^pr^ is VFSA VT. h.,^); 22 
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(on B VDD) 

DAT31:0 n 

HIMEM (normally used as\ApR24» but ii can be used as ADR3 1 and leave 2GB of upper 

address space reserved for MPEG/JPEG boards) 

ADR23:2 

BE3n3E2n.BEln3E0n 
LADSn,LDEVn,RDYn 
M/IOn, W/Rn 
RESET, LCLK 
RDYRTNn, 

EBR0MnA^ADRn/AUXS2 (Enable BIOS ROM Buffers on aU busses or V^d Address • CPU 

Address in Nordic valid address range or memory or Auxiliary Select 2 to 
be used to select she Audio Synthesizer or some otfver audio chip) 
INTR, CLK32K/OVRW, OSC/XVCLK (14.318MH2) 
SUSPIn/BLIn/FCBLANKn, SBYIn/ACTIn/FCEVIDEOn 

(32KH2 clock input / FC Overlay Window Output controlled by VAFCPU, 
S upend Input/ Back-Light Input/VAFC BLANKn I/O signal controlled by 
VAFCPU - pin configuration -and FCESYNCn - FCBLANKn direction and 
HSYNC/VS YNC HI-Z or not; 

Stand-by Input/Activity Input/VAFC External Video Control Input - controUs the 
direction of FCP(7:0]. Pin configuration controlled by VAFCPU). 

Configurations: - VL/PCI/ISA bus, support/not BIOS, 8/16bit BIOS. 

- Need a register bit to select SUSPEND Input or Back-Light Input. 
Default is SUSPEND Input 

- Need a register bit to select Stand-By Input or Activity Input Default is 
Stand-By Input 

- SUSPIn, BLIn, SBYIn, ACTIn arc level triggered, active L inputs. 
In Nordic there is no Suspend pin polarity bit as in Tl (SR8[4]), 

lifltfi: a.In PCI bus, Alpine used ADR17:2 as BIOSA15:0, We assume that all portable 
systems will use a motherboard video BIOS and do not suppon an adapter BIOS in 
PCI. We do suppon an adapter BIOS in VESA VL bus and ISA to facilitate demo 
board design. 

b. EBROMn is active on all bus types: in ISA is generated on Address Decode and 
MEMRn, while in VL and PCI is unlatched address decode. In PCI bus the BIOS should 
be relocatable, an option we do not support That is why we say that we do not suppon 
BIOS in pa. We do suppon lOCHRDYn and RDYnyTRDYn for BIOS accesses too. All 
this logic should already be in 5428 (ISA and VL) and Alpine (PCI). 

c. The 5428 Feature Connector pins are available in all buses. A register bit enables 
them early in the logic to save power when not in use. 

Cirrus ConfideDtial 
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nRAM Interface (for assYmetric. dual WEn 2S6Kx\6 DRAM-O: 
(on DVDD) 

MA9:0 
MD31:0 

RASOn,RASln,CASnAVEn, OEn 
WE0n/CAS0n,WEln/CASln,WE2n/CAS2n,WE3n/CAS3n 

Configurations: symccric/assymctric DRAM, dual WEn/CASn 

Note: a) For dual CASn DRAMs, the WE0n:WE3n pins become CAS0n:CAS3n, while 
CASn becomes WEn. 

b) Two RAS-cs are used for two banks. 

c) OEn is not actually needed as we use early write. 



(MAVDD, MAVSS feed mclk clock synthesizer, VAVDD, VAVSS feed dclk clock synthc- 
sizcr) 

MAVSS, VAVSS, MAVDD, VAVDD, 
MFILTER, VFILTER 

(Can we design a clock synthesizer without an external filter?) 

CRT Interface and RAMDAC related pins: Hi 
(DAVDD, DAVSS feed aU RAMD AC custom layout) 

R,G J (analog) 

IRcf, DCVDDl, DCVDD2, DCVSSl, DCVSS2 

HS YNC , VS YNC TO (these two pins arc on BVDD ) 



FLAT PANE!, and Pmr Management Intcrfatt (on PVDP); 21 

R7/FCP[3], R6/FCP[2], R5:0, G7/SUSPSTn/FCP( 1] 
G6/SBYSTn/FCP[0), G5:0, B7/M0D, B6/FCVCLK, B5:0 
(use slow edge pads and stagger them modulo 4) 
FPVDCLK, LLCLK, LFS, FPDE, (use slow edge output pads) 
FPVCC, FPBL, FPVEE 

Notes: 



Cirrus Confidential 
Business Information 



CL 146397 



b. R7:6, G7:6, B7:6 (24 bit TFT panel extra video data out pins) 

c. We need also bits for SUSPST and STANDB YST, PANEL-ON/OFF, PANEL- 
IN-POWER-UP-or-DOWN. 

d. We assume that the 24bit TFT panels do not need external MOD. 
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c. No NPD pin. 

f. FCP[3:0] pins arc I/O-s whose direction is controlled by FCEVTDEOn in 
VAFC configuration. FCVCLK is the clock that clocks them in and which should 

be used to clock them while they are displayed or at least to rcsynchronize them before 
being latched on the internal clock. FCVCLK is always an input when in VAFC configura- 
tion. 

g. Nordic- IM facilitates NTSC output by providing RGB 6:6:6 just before DAC on 
the R5:0. G5:0, B5:0 when in a special mode. It also provides odd/even frame signal and 
true Display Enable in sync with the RGB. Nordic- IM will run in tcrlaced mode when in 
NTSC Out mode. All the needed signals will be comming out on the Flat Panel Pins in the 
NTSC Out mode. 



Audio Port (on ADVDD)! 

SDO (SEriai Data Output to CODEC pin SDIN) 
SDI (Serial Data input from Codec pin SDOUT) 
FSYNC (Frame Sync Output) 
SDCLK (Serial Data Qock I/O ) 

D/Cn/AUXSl (Data/Control Select Output or CS4231S Chip Select for the ISA bus) 
PDN (Power Down Output) 

Note: These pins can be used as extensions for 24 bit TFT panels, in which case the chip 
does not support the audio port Note also that CS4215 has Resetn pin. 

Cirrus Confidential 
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MiscellangQii^ Pin^; 

Following pins on MVDD: 

TRWn I (Test Latch Load Enable, acdve L - for pinscan & test mode) 

SW2 I ( Switch #2 or reserved for SDRAM suppon in the funire) 

SWl/MCLK/XMCLK I/O with PD controlled by XReset 

(Switch #1 or mclk driver buffered output for tesing and debug 
or external mclk for testing; a special register bit disables this 
output in normal operadon for power savings. 
Default: Input on which either SW2 or XMCLK comes in. 
Only if the special register bit 

is set, this input becomes output and outputs MCLK from the clock 

synthesizer for testing. 
The special register bit defaults 0 = the pin is 
configured as Input Please note that a h/w configuration PU/PD 
conn-oils if the actual internal mclk comes from an internal or 
external source, but this PU/PD does not control if 
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SW2/MCLK/XMCLK is an input or an output) 

RES4CKE O NC Pin Reserved for Funire Nordic chips 

Following Pins on BVDD: 
SWOA^CLK/FCDCLK I/O (Switch #0 Input or vclk driver buffered output for 

testing and debug, or VAFC Dot-Clock Out ; 
Default for this pin is Input on which SW#0 is applied. 
VCLK and FCDCLK is the sanw signal, the name is 
diferent to case reference to VAFC spec ) 
Following Pins on PVDD: 
FCP[7;4] I/O Feanire Connector Data Pins bits 7 to 4. 

The other Feature Connector pins are shared with some 
panel or host bus pins. 
FCESYNCn/RES4SDCLK I 5428 Feature Connector ESYNCn pin - controUs the 

direction of FCBLANKn and its effect and tri-statcs HSYNC and VS YNC. 



Svstem/Bus Tnterffl«> Sitmal Mappiny 

(See 54xx Reference Manual for Feature Connector Pins Description: FCyyyy) 
TABLE 4. VESA-VL<» PCI bus <•> ISA bus Pin Mapping 



VESA.VL 


Intel*Pa 


ISA 


HIMEM ' 






ADR23:16 - 




LA23:16 


ADR15:9 ^ 




SA15:9 


ADR8 


PAR 


SA8 


ADR7 


STOPn 


SA7 


ADR6:2 




SA6:2 


BE3n 


C/BEn3 


SAl 


B£2n 


C/BEn2 


SAO 


BEln 


C/BEnl 


SBHEn 


BEOn 


C/BEnO 


RFRSHr 


DAT31:22 


AD31:22 




DAT21;19 


AD21:19 




DAT18 


AD18 


MWRn 


DAT17 


AD17 


I0CS16n 


DAT16 


AD16 


IRQ 


DAT15:0 


ADIS:0 


SD15:0 


RESET 


RESET 


RESETDRV ?? 


LADSn 


FRAMEn 


BALE 


LDEVn 


DEVSELn 


MCS16n 


RDYRTNn 


IRDYn 


AEN 
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TABLE 4. VESA- VL <•> PCI bus <•> ISA bus Pio Mapping 



VESA.VL 


Intd.Ra 


ISA 


W/Rn 


IDSELfl 


lORji 


M/lOn 




MRDn 


LCLK 


CLK 


lOWn 


RDYn 


TRDYn 


lOCHRDY 


EBROMn/VADRji 


VADRn 


EROMn/VADRn 


INTR 


INTR 


ZEROn 



Notes: 1. SW2, SWl/MCLK/XMCLK and SWO/VCLK pins arc 

normally used by the BIOS as panel type switches readable on SR24[2:0]. 

2. XMCLK and XVCLK (on OSC/XVCLK) arc needed for manufacturing test of 
the chip. When they are used, SR24[1 :0] will wiggle at clock rate and they should 
be masked on the tester. 

3. MCLK and VCLK arc needed for manufacturing test of the clock synthesizer 
and for chip debug. 



Digital, Mixed Voltog^ Power Pirn; 21 

BVDDl, BVDD2, FPVDDl, FPVDD2, MVDDK MVDD2, ADVDD, 
CVDD1:4, (BVDD goes now to HSYNC and VSYNC) 
VSS1:11 

Total Pins Used: 208 (with no pin left). 

Pinout Mftdifiations in rev, U relative to rev, 3,7 09/ll/?3 

1 . Took-out Whisper Suppon Pins: WWRn, WRdn, WAD[3:01, FPCn. 

2. Reduced the number of CPU Address Pins: ADR[24:27] went-away. Use HIMEM to 
place the chip outside 16MB of memory for linear addrcsing. 

3. Killed CRTVDD and placed CRT Interface on Host Bus VDD. 

4. Introduced VAFC pins in a unique pinout configuration in both VESA VL and PCI. 
Added VAFCPU a pull-up to enable VAFC (VESA Advanced Feature Connector). 
ADR[27:24] VAFC pins, and R[7:4), G[7:61 , EROMnA^ADRn, SUSPI/BLI. SB YI/ 

ACT! get a configuration for VAFC -> total 14 pins. 

SWO/VCLK wUl be used as VAFC VCLK, losing S WO pin as panel type when VAFCPU 
is used. 

In PCI bus, no ADR pin will be shared with VAFC. 

ASWOPU (Alternate Switch 0) will be added on MD pins to replace SWO pin when 
VAFC is enabled by VAFCPU. ASWOPU will read-back in the same register bit as SWO, 
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so the BIOS will not feel any modification in the reporting scheme. The chip will draw 
more power in suspend with VAFC. 

5. Moved SW2, SWl/MCLK/XMO-K the two reserved pins (one obtained by killing 
CRTVDD)and TRWn on MVDD to prepare for SDRAM pin compatible option in the next 
Nordic that supports SDRAMs. Marked them as "reserved for SDRAM pin name". 

It looks that TRWn will not be needed, but it was moved on MVDD so that in case u is 
needed, it is available (in this case we'll need an extra switch for SDRAM suppon or at 
least to disable TRWn test mode effect). 

6. Rearanged VAFC pins as pins R4 and R5 were used by VAFC - an error. 



Configurtng NnrdtclM 

If Temunaior used specially assigned pins to configure the chip, Nordic-IM will use 
some of the MD31:0 pins sampled on the Reset trailing edge, similar to Mustang. 
The pad cells will have an active pull-down controlled by an extended Reset signal. 
The pull-down resistence will be about 75KOhm. An external pull-up less than 60KOhm 
is needed only if the option is used. In Suspend, the MD pads are inputs and the DRAM 
OEn is H so no DC current is drawn by the configuration h/w. An external resistor is 
needed only if the configuration pin has to be H at Reset 

All h/w configuration latches are read accessible via I/O. The h/w configuration is 
latched on Reset trainling edge, (these latches were r/w, with s/w PU read, having only 
read is enough). 

We'll define the configuration pins to minimize the number of external resistors: 



CPU Bus Configuration: 



On MD18:16 & -> no external PU = 32bits VESA VL bus at 33MHz or less bus clock 
&MD23 ->MD16PU = 32bits PCI bus with Burst PU called "PCIPIJ" 
->MD17PU = 16bitsISAbus PU called ''ISAPU" 

-> MD18PU = 32BIT VESA VL BUS AT 50MHZ BUS CLOCK 

PU called "FVLPU 

-> MD23 PU = 32bits PCI bus no Burst PU called "PrTTsmPU- 
This is a reserved configuration in case burst does 
not work on a PCI bus. 



Reads-back in SR22: 



PCIPU onMD16 -> SR22(0] 
ISAPUonMDl? ->SR22(1] 
FVLPU on MD18 -> SR22(2] 
PCINBPU on MD23 -> SR22[7] 
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Clock Configuration: 

I OnMD19 (reads back on SR22[3]) 

-> no external PU = internal MCLK and VCLK clocks, from the internal clock 
synthesizer 

I -> MD19 PU = use external clocks from SWl/MCLK/XMCLK and 

OSC/XVCLK 

PU callgd"XaKPU" 
This PU is used for manufacturing tcsL 

One reg. bit is needed if internal clock is selected to control outputing mclk on the 
MCLK/XMCLK pin = 1 if use internal clock then ouq)ut it on SWl/MCLK/XMCLK 
pin. -> SR23[0) is this bit 



Memory Configuration: SRF[0] 

No Pins, Use Two Register Bits -> 2CAS/2WE bit=H 2WE, bit=L 2CAS (default =L) 

-> Symetric/Asymetric bii=H Asym., bit=L Sym. 
(default=rL) 

I BIOS Support: (reads-back on SR22[6) for BI0S8PU) 

Nordic- IM supports 16bit or 8bit BIOS and only in ISA bus configuraoons. 
The BIOS is always supported when in ISA. 

On MD22 -> no external PU = 1 6bit BIOS 

-> external PU = 8bit BIOS (no MEMOS 16n decode on COOO) 
This option is mosdy for debug in case 16 bit BIOS range decode is not fast enough. 
If the BIOS suppon is disabled, this configuration is don^t care. Called "BlO.SSPn" 
I Please note that Nordic-IM supports COOO BIOS only in ISA. 

In a normal note-book the BIOS is at E(XX):0, not supponcd by Nordic; so no external 
component is needed. 

Sleep Address Selection: 

On MD2 1 : Sleep Address Selection (reads-back on SR22(5]). 

-> No external PU = sleep at 3C3[0] - to be used when Nordic is on the 

Mother-board (most cases) 
-> External PU = sleep at 46E8(3] - to be used when Nordic is an adapter 
(like a PCMCIA card and/or an adapter to tum desktop into an 
I environment friendly PC) Called: S46PU 

Cirrus Coofideotial 
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Note that Nordic- IM comes*up awake, though this has to be cleared 
with the BIOS group. 

Feature Connector Configuration: (reads-back on SR24[7]) 
On MD25: 

-> No external PU = no Feature Connector Suppon: outputs used only for FC 
are forced L, I/O arc forced inputs, I/O and inputs are forced on the chip so that they do 
not take power if not connected externally. 

-> External PU = All pins needed for FC including OVRW are active. 
Called: VAFCPU 

On MD26: Alternate SWO Selection (Reads-back on SR24[0] when SR24[7] is 1 ) 

When SR24[7] is U SWO pin is forced to ouq)ut DCLK and this external PU 
latched on Reset ttailing edge plays as SWO. It reads back at the same bit 
as SWO docs. 

-> No external PU = SWO reads back 0 in SR24[0] 

-> External Pu: SWO reads back 1 in SR24[0]. 

I Total: 10 H/W PU configuration options. 

In normal operation with FC enabled up to three external PU-s may be needed (bus type 
if not VL and FC). 

In normal operation with FC disabled up to one external PU-s may be needed (bus type 
ifnot VLandFC) 

Sunmiary of PU/PD Configuration Pins and Register Bits where they can be read-back: 



SR22 fTrOl H/W Configuration Read Register #1 

Read only register, written on reset training edge by activating PU/PD on MDi pins. The 
PD-s are inside the pads active only during XReset (extended reset). 

I [7] 32bits PCI bus no Burst h/w PU configuration on MD23. It is called "PCINBPU" 
(read only bit). 

This is a reserved configuration in case burst does not work on a PCI bus. 

[6] Select 8 bit BIOS suppon (if 1). Otherwise 16 bit BIOS suppon if the BIOS 
I suppon is at all enabled. PU on MD22. 

Cirrus CoDfidential 
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[5] Resereved for Sleep Address Select: reads back S46PU (MD2 1 ). 

1 = 1/0 address 46E8[3] as sleep address (needs external PU). - jir^n-, 

0 = 1/0 address 03C3(01 as sleep address (no external PU is needed). 146403 

I [4] Reserved 

[3] Select external clocks: MCLK and VCLK on SWl/MCLK/XMCLK and OSC/ 
XVCLK. (default: internal clock synihesizen SWl and OSC). 
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PU on XCLKPU onMD19. 

0 = internal clocks with the pins used as inputs for panel type switch #1 and OSC. 
If SR23[4) and SR23[0] are K SWOA^CLK and SWl/MCLK/XMCLK, 
respectively become VCLK and MCLK outputs respectively, for test purposes 
(only if SR22[3]=0 MCLK can be seen, but VCLK can be seen even if SR22[3)=I 
aslongasSR23[4]=l) 

1= SWl/MCLK/XMCLK and OSC/XVCLK become XMCLK and XVCLK inputs 
generating directly chip MCLK and VCLK without clock synthesizer. The clock 
synthesizers arc powered down if SR22[3]=1. 



(2] Selea VESA VL Bus at 50MHz 

1 = VESA VL bus at 50MHz selected (needs external PU on MD18) 
0 = VESA VL bus at 50MHz not selected 



[1] Select ISA Bus with PU on MD17. 

1 = ISA bus selected (PU on MD17) 

0 = ISA bus not selected (no PU on MD17) 

[0] Select 32bit PCI Bus with PU on MD16. 

1 = 32bit PCI bus selected (PU on MD16) 

0 = 32 bit PCI bus not selected (no PU on MD16) 

If [1:0] = 00 (i.e. no external PU on MD17:MD16) 32bit VESA VL bus is selected. 
No more than one PU on MD17:MD16 should be used. 

Note: In AVGA3, CF14 is "Enable Local BUs Address Latching Interface". .Mpine does 
not have this configuration bit We need to do what was done in Alpine to get rid of this 
Configuration Pull-up/PuU-Down option. CAN we? WAs this done. Dwarka? 

SR24 Panel Type Switches Register 

[7] VAFCPU (VESA Advanced Feature Connector External Pull-up) Read-back. 
If external pull-up (the bit read-back 1 ) then all VAFC pins are configured for Video Port. 
Otherwise they have other functions or are disabled if no other function. (Disabled= the 
inputs are foccd = the TTL and CMOST threshold controls are off & the outputs are tri- 
siaied. It actually reads back what is latched on Reset on VAFCPU. VAFCPU is on 
MD25. 

[2:0] SW2:0 pins read back (read only bits) Please note that bit [0] reads back SWO if 
VAFCPU (SR25[2]) is 0 and ASWOPU if VAFCPU is l.ASWOPU is on MD26. 

Configuration Register Bits needed: ^^^^^ Confidential 
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Svmetric/Asvmetric DRAM -> SR8(7] in Tl , CF13 in AVGA3 

=>SRF[1] 0 = Symctric DRAM Default: 0 
1 = Assymetric DRAM 
This bit is read only in AVGA3 (reads back CF9)» but it is writable in Tl . It con- 
trolls MCLK frequency as an alternate to SRIF. We will use only SRIF to program 
MCLK frequency in Nordic. The default MCLK frequency will be 39.374MHz, corre- 
sponding to SR1F[5:0] = 18H=22D. This frequency fully meets the spec for -80 256Kxl6 
DRAM-s. 



Two CAS or t wo WE DRAM -> pin 72 in TL CFI2 in AVGA3 

=>SRF[0] 0 = 2WEDRAM (Dcfault:0) 
1 = 2 CAS DRAM 

1 6 or 32bit wide Video Memory f One or Two l^f^Kx 1 DRAM-S or SDRAM-s) 
-> not in TL SRF[4:3] in AVGA3 (01=i6bii, 10«32bit) 
=> SRF[7,4:3] will be used in Nordic with the same encoding as in AVGA3. 

(1 1 is reserved for 64bit wide). Default: 10 (32bit). Sec Table next page. 

Please note that we have room to add other types of DRAM-s (SDRAM-s 

for instance). 



In AVGA3 SR8[0] is "CS OUt to EEPROM" a feature Nordic does not Suppoa 
Nordic will not change the meaning of AVGA3 bits unless they are read only 
(like the pins or external PU read back). 

SR8[2:0] are in Tl the read-back bits for SW2:0 input pins, but AVGA3 uses 
them for EEROM programming so we moved SW2:0 read back to SR24[2:0]. 

In Tl SR8[7] is symmctric/assymetric addressing... in Nordic this is SRF[1]. 

Two or one Bank 32hit uHrfi> HR AM 

-> not in TL SRF[7,4:3] in AVGA3 (00=8bit, 01 = 16bit, I0=32bit, 1 l=64bit. SRF[7] 
controls if 2MB of Video memory are available with 4x512kx8 -0- or with 4 256ICxl6 
DRAM-s, twoi banks - 1 -). It seems that in AVGA3 to support J MB with two 256Kxl6 
dram-s and 32bit wide bus. we select 32bit wide and SRF(7]... but I do not exactly know 
how this configuration is selected. 

=> SRF[7,4:3] in Nordic, will select the Video Memory Configuration slightly dif- 
ferenUy than in AVGA3 and Alpine. See the foUowing table. 

Cirrus Confidential 
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32bii, 2MB=4x512Kx8 

16bit, 512KB=lx256Kxl6 

32bit, lMB=2x256Kxl6 (default) 

Reserved (64bit in Alpine) 

32bit, 2MB=4x256Kxl6, Two Banks 

Reserved 



new 0 0 0 

0 0 1 

0 1 0 

0 1 1 
new? 1 0 0 

1 0 1 
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1 1 0 Reserved 

I 1 I Reserved 

PRAM Timing SClcc; (shon RAS or long RAS) 
.>SRF[2]inTl and AVGA3 

=> SRF[2] in Nordic, default 1 = shon RAS (3.5 L, 2.5H) 

BIOS 48ICB or 32iCB .> not in Tl: CF8 in AVGA3. In Tl SR8(4] is Suspend pin polarity. 

In Nordic Suspend pin is always acdve L (0 on pin puts the chip 
in Suspend). 

=> SR23[2] in Nordic =0 32KB BIOS (default=0) C0000:C7FFF 
=1 48KB BIOS : C0000:CC3TF 
The inidal BIOS code should be placed in the first 32KB starting at address COOOO. 

BIOS ROM ZERO* wait select in ISA and fast timing in VL bus 
-> not in Tl; CFl in AVGA3 

=> SR23(1] in Nordic =0 no ZERO wait state for BIOS in ISA 

and slow, safe BIOS timing in VESA VL 
and pa. 

=1 ZERO wait state for BIOS in ISA, SMHz 
bus 

Output internal VCLK on VCLK/XVCLK nin -> not in Tl or AVGA3 

=> SR23[4] in Nordic =0 if SR22[7]=0, then 
VCLK/XVCLK is an output pin forced L 
=1 ifSR22[7]=0,thcn 
VCLK/XVCLK is an output pin and it outputs VCLK. 



Output internal MCLK on MCLKOCMCLIC pin .> not in Tl or AVGA3. 

=> SR23[0] =0 (default) force L on the pin 
=:1 output mclk 

Suspcndl/BLl bit -> not in Tl or AVGA3. 

=> SR23[5] in Nordic, 0= Suspend pin in Suspend/BLI pin (default) 

1 = BLI pin on Suspend/BLI pin cirrus Confidential 

r,r.^,,r^^. , ^ Busioess InformatioD 

SBY/ACTT hit, -> not in Tl or AVGA3 

=>SR23[6] in Nordic, 0=SBY on SB Y/ACTI pin (default) 

1= ACT! on SBY/ACn pin 146406 

Video Pon Enable hit acnvg in PCI hiiQ .> not in Tl or AVGA3. 

(read only bit, actually reflecting the status of an external configuration PU: FCPU on 

MD25 latched at RESET or under S/W Control) 

=> SR24[7] 0= Video Port Disable at pins to 
save power: inputs are forced. 
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outputs are L. I/O-s are inputs 
forced H in case they are not 

connected in the system. 
If any shared pins, they arc not 
in Feature Connector 
configuradon. 
1= Video Port Enabled at pins. 
If any shared pins, they arc 
now in Feature Connector 
Configuradon. 

Live Video Fnahlg hit -> not in Tl or AVGA3. 

=> SR24[6] 0= disable (default) 
1- enable 

Audio In ffrnnn CS4^1 S to Nordic^ Enablg hit .> not in Tl or AVGA3. 

=> SR24[5] 0= disable (force inputs 

inacdve and outputs L 
disable AI-FIFO and cycles ) 
1 = enable 

Audio Out (from Nordic to CS4215^ Enable hit, .> not in Tl or AVGA3 

=>SR24[6] 0= disable (as above but 
AO-FIFO) 

1= enable 

Panel Tvoe Switch Read-hack -> SR8[2:0] in Tl or SR7[6:4]. not in AVGA3 

=> SR24[2:0) in Nordic, read only, writable on Reset or 
under S/W Control (SR24[3]) 
When SR24[3] whose default is 0, transits from 1 to 0 
SW2:0 pin value is latched into SR24[2:0 which cannot 
be written by 1/0. 

Cross Talk Reducrion Enable .> not in Tl or AVGA3. 

-> SR24[3] =0 disable (default) 

=1 enable • the pinout is configured to suppon 
cross talk reducdon chip. The I/O registers 
for the cross talk reduction chip are always 
decoded, to make things simple. Reserve 
SRFX for this purpose. 

Please note that R9x(l:01 TFT Panel type field of Tl was expanded to suppon 24bit TFT 
panels: 

Cirrus Confldential 
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10 -> 12bit (444) (as inTl) 
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01 -> I8bit (666) (was xl in Tl covering both 01 and 10 !!] 
1 1 -> 24bit (888) -> new in Nordic 

Notes: 

a. If 24bit TFT panel is selected, all related pins will be configured for it and it has priority 
over panel pins configuradon setdngs for cross talk reduction enabled. 

b. If 24bii TFT is not selected then MOD is sleeted on M0D/B7 pin. 

c. If STN Panels Cross Talk Reduction support is selected, and TFT type is not 24bits, 
then the Qoss Talk Reduction suppon pin configuration is selected. 

d. If 24bit TFT is not selected, then SUSPST is selected on G7/SUSPST and SB YST is 
selected on G6/SBYST and MOD is selected on M0D/B7. 



Other Register Related Tnnir^ 

(See Dordi€*regs«rev#.lst where # is the latest one) 

Bins srrfltrh RggKters #S and #6 (2 extra required) (r/w) 

SR28:SR29[7:0] are scratch registers. 

Note that SR9, SRA, SR14 and SR15 are AVGA3 scratch registers which wc keep in Nor- 
dic. Also there are 13 18 bit scratch registers in the RAMDAC is SRI 2(1)= 1. 



R9x - TFT Panel Data Format 



[7:5] Reserved 

(4:2) Select a 0 to 7 shift-clock delay from the internal character clock counter 

(8 VCLK/Charactcr Qock) to TFT panel HSYNC (LLCLK) signal -> as in TL 

(1:0) TFT Panel Type: 

00 •> 9bit (333) (asinTl) 
10 -> 12bit(444) (asinTl) 

01 -> 18bit (666) [was xl in Tl covering both 01 and 10 !!] 

1 1 -> 24bit (888) -> new in Nordic Clrnis Confidential 
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CR1B(7,434] (RIB in schematics): 

[7] Disable Text Cursor Blink in Tl. Do we use this feature in Tl? 

Enable Blank End Extensions in AVGA3 
[4] PCLKO (Panel Clock) no divide by two control in Tl. 

1 am not sure this bit is acmally needed in Nordic. 
[3] IRQ Every Frame or Every Other Frame ? Is this bit used inTl ? 
[2] Not Used at All inTl. 

I think that all these bits arc not actually used. Are they needed ? -> Robin. 

CR1C[7:0] & CRID[7:0] 

Are important LCD and Power Management Registers in Tl and Overlay Registers in 
Alpine. These registers are not in AVGA3, but because they arc used in Alpine we may 
move them to CR2Cr7:0] and CR2D[7:01, which requires one more CRTC Index Regis- 
ter Bit So: 

CRIC -> CR2C & CRID •> CRID in Nordic relative to Tl. 
SRF[7] 

In Tl is CRT Refresh Disable. This bit gates /FB/RWC(5] in FB sheet 6. In AVGA3 is 

DRAM Two Bank Configuradon select bit 

I don*t think that this bit is used in Tl ? -> Robin. 

SR16 

In Tl is used to control the pads for power and threshold. In AVGA3 is not used. In Alpine 
is CRT FIFO demand threshold and other things ([4:0] are used). 

Move SR16 bits of Tl to SR20 to avoid contention with Alpine. Increase SRX Sequencer 
Register Index to 6 bits. 

SRIA 

In Tl is used as Test register. In AVGA3 and Alpine is Signanire Generator Result Hi. 
Move Tl SRIA bits to SR21 if it is not replaced by a similar register in AVGA3. 



Nordic Revision and Mask Codes 

Nordic Revision: ?? 
Nordic Mask Code: 00 
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LIVE VIDEO SCHEME PP.CPOSAl. 

by SASHA EGLIT rev. 3 :6/l"''93 



OVERVIEW 



This proposal is related to Real-cime Laserdisc-qr-aliiy live 
video system for notebook- type of PC, 



1.1 GOALS 



The nain goal of proposed design is to achive high -quality 
live video on LCD based machine while minimizing cost of 
hardware embedded into LCD controller, which will provide for 
preserving of low PC cost for users which will not need live 
video. It is highly desirable to avoid any expensive solution 
which will be common for all system configurations. We will try 
to keep additional hardware cost for LCD controller under SI. CO 
(SI . 50 worst case) . 

By the term "High Quality live video" we understand real- 
time video with 640x480 pels (square pixel mode) and 30 frarr.es 
per second (fps). Informally, image quality should be comparable 
with one provided by LaserDisc medium. 

To be able to run under MS Windows, video data strear. 
should be genlockable to VGA image. 

Primary output devices for this system will be LCD panels 
(mostly, color ones; but it should be possible to use r.ono 
panels. too); but system should be simul-scan capable (mostly, 
for marketing reasons) . 

Also, there are roumors - it will be good if we can cap- 
ture video clip in real time for editing and creating animated 
presentations (at least, if system will provide this feature 
without additional cost:). 
We also think, design should be based on existing explicit or 
implicit standars (like local buses of different kinds, PCMCIA, 
etc. ) , 

1.2 SCOPE OF THIS MEMO 



This memo covered video subsystem from digital YUV video 
bus with 4:1:1 or 4:2:2 subsampling to LCD interface. Front end 
for this system can be any popular digital video decoder chipset 
(For example. Philips DMSD and DMSD2 chipsets) . 



Particulary, we will discuss implementation of basic part, 
which will be implemented on LCD controller chip. We will also 
do some system bus and video memory bandwidth calculation to get 
pessimistic estimation of possible system overhead and worst- 
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case limicacions. 



2.: TRADITIONAL WAYS 



At present, there are lot of icnowr. different approaches to 
get live video into cor.puter display device. The most popular 
one is overlay-based schene. In this scheme. VGA controller 
provides switching of data source for last staoe of data rath 
(for instance, DAC data bus) between VGA video controller data 
and real-time video overlay data. This approach has several 
advantages for desktop-type PC: it required minor modi f ica tic.-, 
of VGA controller (usually, color keying is the only thing which 
is done on VGA side), easilly provide high enough data rate 
nesessary for live video, doesn't consume video buffer 
bandwidth, doesn't required complicated video 

compressors /decompressors and even provide some degree of VGA 
mode independence. 

For LCD-based machines this approach has some disadvan- 
tages, though. Main problem, from our point of view - this 
scheme doesn't provide flexability for PC manufacturer - this 
guy have to include live video support into every system he 
makes. This problem arise because overlay scheme introduce som.e 
custom (well, it can be informal semi -standard from VESA) video 
data bus. For desctop it's fine - this bus exists on add-on 
VGA/Video board only and doesn't introduce additional cost for 
basic system configuration. We think, this scheme can be a 
problem for laptop- type PC, because each system should have cus- 
tom video bus on computer board, even if end-user doesn't have 
any intention to use live-video option. Overlay-type scheme can 
easilly introduce substantional extra cost just on board-level. 

Also, desktop VGAs have Feature Connector (in most cases, 
at least). Thus, overlay video bus usually will not introduce 
additional requirements for 10 pads. In laptop world, this 
scheme will cost us at least 10 pins (for 8 bit bus), which will 
also increase overall system power consumption. 

Panel interface-based overlay scheme looks much better in 
this sense, but has serious problem - impossible to have 
simulscan (marketing don*t like this) . 
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Other problem with overlay - lack of modularity on system 
level; this means, if you bought notebook without live video 
(but with LCD controller which provides overlay capability) and 
you would like to add this nice feature later, how you can do 
this? There is no "slots" in most laptops (how's about sub- 
notebooks?) . Overlay scheme can lead to some custom video con- 
nector for add-on box or it can be PCMCIA port with custom 
interface addition - all this solutions doesn't looks too 
attractive for PC manufacturer (additional cost, size, weight, 
etc) . Any customizing of PCMCIA standard port will limit flexa- 
bility of laptop designer and will looks like atempt to sell a 
"bundle" - LCD controller and custom PCMCIA host adapter. Also, 
overlay scheme will require genlocking of live video part to LCD 
scaning, which also can cost something. 
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Lasc buc not lease, overlay sche.T.e ioesr.*- ar.sver que3i:;r. 
about realti.T.e video capcuring - :usr zo be able zo wrize '".zez 
data on the disk we'll have to ccr.press it fat least, 5:1 
ration) . 

Sor^e .Tiodifi cat ions of overlay scheme using custon video bus 
on the input side of VGA r\emory (not output side, as traditional 
overlay does) . This potentially will sir.piify genlocking and 
can provide a possibility to use VGA memory for de:.nterlacing of 
video image. Disadvantages: live video vill generate huge .T.er.ory 
bandwidth requirement, which, in turn, will limit site and. or 
FPS of live video; this limitations can lower quality of live 
video image to unacceptable level (we talking about prccutt 
which will be in production in 1994 (hopefully) ) . Also, cost zz 
this approach on LCD controller side will be significant - large 
FIFOs for ALL components, for example. Seems like this way is 
costly and provide limited quality; from our point of view, 
quality limitations are the real killer of this scheme. 

There is other way to get live video: real time data 
compress ion/ decompression . This way have several advantages - 
LCD controller doesn't required additional 10 pads; since all 
data transfer happens through the system bus, there is no need 
for special video bus to compare with overlay scheme; this way 
is natural for applications which required real-time video cap- 
turing; embedded cost of decompression can be very low (in case 
of highly asymetric coding /decoding methods) . This approach 
isn't popular for desktop applications because of higher overall 
subsystem cost to compare with overlay scheme; but for laptops 
and notebooks it can be really attractive. For our 'understand- 
ing, main advantage of this way is ability to separate cost from 
LCD controller and basic system configuration PC (means if user 
doesn't want to pay for live video option he'll not have to) . If 
video subsytem can be done as PCMCIA card, PC design will not be 
affected at all (some BIOS mods may be nessessary, of course) . 
Also, decompression capability of LCD controller can be very 
usefull for video clip playbacks and truecolor still image view- 
ing in color mapped environment (for example, user will be run- 
= ning Mode 12 for Windows perfomance reasons but it still will be 

possible to view truecolor (24 bits/pel) images in one or more 
'„ windows. Also, in case some customers doesn't want live video 

hJ at all, it's possible to disable decoder by using bonding option 

U without substantial price increase (may be usefull for marketing 

rr guys). 
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Some disadvantages do exist, though. First of all, 
currently popular •professional* compression schemes like MPEG, 
JPEG2, P64 etc, are very costly from hardware point of view and 
they are more or less symetric - this means, decoder and encoder 
are based around common part (like OCT transformer , for example). 
Currently, it's seems quite unrealistic to make MPEG-style 
decoder under $2.00 (especially, if we're talking about adding 
this stuff to LCD controller with die size around 380 mil/side) . 
It also will introduce power consun^tion problem. 

Some -cheap" methods are asymettric in general (like 
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CinePack, for instance) and can be done in reasonably .r.excen- 
sive way (probably under S2.00); but seems like all cf ther. r.ave 
image quality problem. Most of this methods assume small s.te zz 
image {from 160x120 pels to 320x240 pels); also, most c: them 
can deal with update speed less than 20 FPS (in general 15 TPS 
is not bad) . Most of this compression schemes usually have 
relatively poor intraframe compression perfomance wich is com- 
pensated by high interframe compression ratio (for exam.ple. ir. 
CinePack key frame will be transmitted once out 15 frames). This 
can create highly visible quality loss for dynamic-type of video 
data (sport footage, for example) . 

2,2 WHICH WAY TO GO? 



We think, approach with data compression definitly has 
advantages for laptop- type machines, especially if it can be 
done under SI. 00 of cost embedded to LCD controller. The later 
requirement was forcing us to find some inexpensive way for 
video compression/decompression. The target compression ratio 
was assumed to be between 8:1 to 10:1 (for 24 bits/pel video 
data) . This will generate sytem bus data flow about 3 
Mbytes/sec for 640x480 picture at 30 fps. This compression 
scheme doesn't need to be compatible with existing methods as 
long as somebody provide inexpensive encoder for this compressor 
(this is closed circuit type of system) . Also, most expensive 
part of decoder (like yuv->RGB converter) can be shared with 
CinePack decoder for CD ROM playback. 
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2.3 SUGESTED ARCHITECTURE (SYSTEM LEVEL) 



Let's assume we have (really) inexpensive decoder of 
compressed live video data which can provide reasonable image 
quality (remember, goal is LD quality (worst case, SVHS or HiS 
type VCR)). Let's also assume, we are geting this data through 
local bus on i486-based machine. The source of this data will 
be PCMCIA card plugged into standard PCMCIA host adapter (like 
Cirrus 6710). Now we're ready to calculate some figures: 



Image size is 640x480 pels; 

total number of pels is 307200 per frame (300k); 



Lets assume, we have dumb coder with 3bit/pel compressed data 
without any interframe compression (8:1 intraframe compression). 
This will give us following data flow rate: 

307200 pels/frame = 921600 bits/frame = 115200 
bytes / frame ; ^^^^^ Confidential 

At 30 FPS this will give us Business Information 

115200 • 30 = 3456000 bytes/sec = 3375 kbytes/sec = 

3 .296 Mbytes/sec. 
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For local bus this data rate is a peanuts. For i43S this is also 
not a problem, especially if we gonna '.:se MO vs ' INS /OUTS type o: 
instructions (sorry, rnnemonics may not be correct - we r.ean 
string move and string 10). Kow s about PCMCIA? 



Pessimistic timing option for PCMCIA is oased on 
standard ISA timing; let's check this case to see 
some worst-case limitations: 

We assume 80ns Address Setup, 280ns command time 
and 40ns Address hold time (normal ISA timing) . 
This yield 400ns typical cycle time and 5MBytes/sec 
bandwidth for 16bit wide access. 



So, even with "safe" timing assumption compressed video data can 
be easylly trans fered over PCMCIA port. 

All this calculations show the possibility to implement 
suggested architecture on the system level. 
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2.4 THAT WILL BE GOING ON INSIDE LCD CONTROLLER 



Let's calculate memory interface bandwidth requirements for 
case under consideration. We'll assume 32-bits wide memory data 
path and worst case for videocontroller and frame buffer 
activity - SimulScan and Color Dual scan STN panel. 

We'll also assume FIFOs are based on threshold-triggered 
arbitration policy and have reasonable depth (like 16 or 24 lev- 
els) . For simplicity we'll also assume fixed threshold equal to 
half o£ the fifo size. 

To be on a safe side, we'll assume Vertical retrace time 
and most part of horizontal retrace time will be used 
exclusively for refresh, fifo prefetch and hardware cursor 
access. This will give us pessimistic estimation of bandwidth 
requirement. Now, lets calculate total ntunber of Read/Write 
cycles per line. 

Compression scheme we trying to play with is based on 4x4 
pels block for luxna channel and 8x8 pels block for chroma (4:1:1 
chroma subsampling) . Each block will be encoded into 32 bits 
long record {1 DRAM cycle per block, actually) . Lets also 
assume decoder are REALLY dumb and will fetch chroma blocks for 
each line: this will greatly simplify decoder/ sequensor design 
(remember, we have to be under one buck!), even if it will 
introduce some bandwidth loss (we will read two times more 
chroma data as we really need) . For single frame 640x480 pels 
we ' 1 1 need : 

Cirrus Confidential 
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80x60 = 4300 blocks U ichromal 
80x60 = 4800 blocks V (chroma) 

Total number of blocks per frame is: 
1S200 * 4800 - 4300 = 28800 blocks 



Now, for 8 lines of daca (640 pels each) we will need to write: 

320 blocks Y * 80 blocks U * 80 blocks V = 48C clocks. 
Thus, total number of write cycles per 8 lines will 

be: 

480 W cycles. (average is 60W per line). 

On the read side, we got some bandwidth wasting due to si.Tipli- 
city of decoder design. So, lets calculate number c: read 
cycles on per line basis (our decoder doesn't have any interline 
memory) . 
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For each line we have to read: 

160 blocks Y + 80 blocks U * 80 blocks V = 320 

blocks/line 

(remember, 1 block = 1 memory access) . 

By adding average 60 words writing per line, we'll get: 

320R + 60W = 380 cycles/line. 

The other major player on DRAM side is frame buffer. For DSTN 

(worst case for us) we will need: 

Each line is 640x3 = 1920 bits in and out. 

This will give us 60 write cycles and 60 read cycles; 
total will be: 

120 cycles/line Cirrus Confidential 

Business Information 

So, for each line we have to perform 

120FB + 60CPU ♦ 320VIDEO « 500 cycles / line. 
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How long iz will take for us to make 500 DRAM cycles? '.eis 
assume we're running on SCMHz (jusc for siTipliciry. because XCL-: 
period will be 20ns) . Also, lets assume we will do at least 12 
CAS cycles per RAS cycle (i.e. FIFOs are seating at the thres- 
hold of 12 and have normalized depth of 24). Now: 



We'll need 500 / 12 = 41.6(6) 
Thus, worst case we'll have to do 

42 RAS cycles / line. 
Each RAS cycle wasting 5 MCLKs, so total loss is 
42 * 5 = 210 MCLK / line. 



Each CAS cycle is 2 MCLK. 

To do 500 CAS cycles we'll need 

500 • 2 = 1000 MCLK / line. 

Total number of required MCLKs is: 

1000 CAS + 210 RAS = 1210 MCLKs / line. 



If we're at 20ns MCLK period, this yield: 
1210 * 20 ns = 24200 ns / line. 
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This is fine, because active part of line in SimulScan mode is 
about 28200 ns. So, we have about 4000 ns of spare time per line 
for good CPU side perfomance. Also, note we're not using 
retrace time at all; LCD controller will do all housekeeping 
activity at that time (prefetches, hardware cursor /hardware 
icons fetching, refresh, etc) . Also, it will give us about 8% 
of unused vertical retrace time to improve CPU side performance 
(Winmark) , because standard VR is 45 lines out of 525 total 
(8.57% of Vertical total) and we're not using it completelly. 

Can we do the same thing at 44MHz MCLK? This is important 
questions, because current -70 DRAMs cannot run on SOMHz safely. 

At 44MHZ we'll have 22.72 ns MCLK period. 

We need 1210 cycles, so cirrus Confidential 

Business Information 

1210 * 22.72ns = 27500 ns exactly. 



This will give us about 700 ns less than active display time. 
So, we definitly can run at 44MHz even with very pessimistic 
model . 

How we can exploit the difference between pessimistic and 
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realistic models? There are two ways co go - per :orr.ar.ce 
ixprovcT.en:: and/or FIFO size reduccior*. Our calculancr.s shews 
-hac It is possible co use FIFOs with r.om^lized dep.h o: :6 
(crheshcld at 3) and still get some additional per:cr.ar.ce 
improvement for Windows . 

HCV/ WE CAN IMPROVE THE SIT-ATION 



We be live, with reasonable increase of complexity o: decoder 
!still probably under one dollar), it's possible to reduce data 
rate to 2bic/pel (24 bits /block) by using incraframe corpressicn 
only (compression race is 12:1). ( we have some working ideas 
about it). For us it's seems highly desirable to avoid interfrar.e 
compression ac that time, because it unavoidably will increase 
decoder price (may be, up to two bucks?!) and Windows driver com- 
plexity. But, worst case, we can do this co avoid average reduction 
2:1 (total 24:1 compression rate). The question is - is it worth to 
do this or not? 

we're not talking about 64bits wide memory data path - this is 
simple and obvious case; but, still, this live video scher.e can be 
justified even in this high-end architecture. The oposite case - 
16bit wide DRAM path - has potential limitations and doesn't seems 
a good way to go (also, it's possible co have reduced size live 
video (320x240 at 30FPS) even on this type of machines). \ 

One thing - live video option will require some special shad- 
ing methods to avoid slow response for highly dynamic video images. 
This is true for both STN Mono and STN colors (espesially. for sin- 
gle scan types). Color TFT support is not an issue, of course. ^ 

For live video capturing it still can be tough to put 3.: 
Mbytes/sec on a hard drive (at least, on low-end machine). This is 
why 24bit/block option may be worth to implement, espesially on 
encoder side. 
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CONCLUSION 

The scheme, described in this memo seems to be possible to 
provide inexpensive high-quality live video option for next genera- 
tion of Cirrus LCD controllers (like Nordic (or Nordik?)). The 
video subsystem will consists of small (under 2K gates total) 
decoder on the board of LCD controller and moderate -complex (under 
ICK gates) encoder/deinterlacer/ scalier chip for PCMCIA cards. 

Also, it seems like proposed scheme has a lot of advantages 
over "classic" overlay scheme in laptop environment. 



It may be worth to try! 
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NORPKC ACTKYITY ANP RESOURCE PLANN^g 

by Rakesh Bindlish and Vlad Bril rev, 1 July 20, 1993 



The main activities in NORDICIM include the following: ^ 

For each new feature in the data base: 

a. Design, Architecture, Register Specifications and the Product Implementation Plan. 

b. Technology development and validation via bread-boarding. 

c. Learning of database AVGA3BR1. 

d. Design of new piece of logic. 

e. Implementation of new logic in schematics. 

f . Environment preparation and verification of new logic 
by itself . 

g. Design Review, timing analysis of critical pathes, static circuit analysis. 

h. Full chip oivironment, initialization and v^fication. 

i. Test Vector generation (which can be started after the TapeOut). 

For the entire chip, to be done once: 

a. Regression porting from 5428 and development for new logic, 

b. Preliminary and final routing. 

The new logic in the absolutely basic feature set (priority A) 

(x/y analysis and design^plement and verify): 

a. Pin-out and top level. 1/1 DP 

b. 32bitCPUbus.2ZLEE 

c. PCI (Peripheral C^ontroUer Interconnect) bus interface. 3/3 PP 

d. Modify tiie existing logic for Pow^ Management (no light sleep support). 4/4 DP. VB 
Includes low power in suspend and stand-by and mixed voltage support and Green PC 

support 

e. Flat Panel support: TFT, single scan STN monochrome and color, dual scan 
STN mono and color , CRTC nnodifications for panel and elimination of light sleep 
logic. 4/5 SdK 

f . Half Frame Buffer logic, its address generation, sequencer modifications, address remap 
for 32bit wide monory (no light sleq)) 4/5 SgK 

g. Half frame Buffer logic, its address generation, sequencer modifications, address remap 
for 16hit wide memory (no light sleep) 1/2 NOT NOW. 

h. Text Contrast Enhancement 1/2 VB/DP 
L Text Vertical Expansion 1/2 VB/DP 

j. BLT improvement: memory mapped I/O 1/1 PP 

t Testability of diffoent modules — will be designed along witfi die new logic. 5/5 MR 
1. Some fixes fit)m AVGA3BR1 and some from 6225/6235. 2/2 all 

Each of these design pieces include all or some of the above listed activities. 

Total work weeks of what we plan to do: 62 for the basic set 

-> 11 WW with 6 engineers -> IS months adding 2 months for a tape-out •> 4^months 
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to tape-out at basic sei -> tape-out mid 12/93. 

Some of the new features which are still being worked out are: 

A. Limited support for 800x600 panels (TFT, STN, dual, single scan): includes 12 and 16 
dot character support - 2/2 SE Jffl or NOT NOW 

B, Limited support for 1024x768 panels (TFT, STN, dual, single scan ?) 2/2 SE, NH or 
NOT NOW 

C H/W Icon on top of h/w cursor with 32bit wide memory. 2/3 SgK 

D. H/W Icon on top of h/w cursor with 16bit wide memory. 1/1 NOT NOW 

E. BLT Improvements as in 5429. 2/2 RB 

E. Audio support for CS42 IS with 32bit wide memory. 4/4 RB 

F. Audio support for CS4215 with 16bit wide mwnory. 1/2 NOT NOW 

G. One Pak h/w acceleradon support with 32bit wide memory. 4/4RB/SdK 

H. Cine Pak h/w acceleradon support with 16bit wide memory. 2/2 NOT NOW 
_„4c=L^35^teQ-Sllg]^ witfi 32bit wide mmiory. 6/6 VB,SE or RB /DP, SE or RB 

J.^^'Fast^iading forUve video and moving images. 2/2 SdK 
K. Cross-talk reduction Whisper chip support 2/2 VB/MR 
L. Dual Display (resolution maximization). 6/8 NOT NOW 
M. Inking Plane. 4/4 NOTNOW 
N. Grey Shade Moping Option 2/2 NOT NOW 

Total work weeks of what we plan to do: 53 (or 45 without large panel support). 

Grand Total : 115 WW (or 107 WW without large panel support) for additions -> 4.8 montiis witii 
6eng 

Add 1 month final verification and 1 month routing and tape-out *> 6.8 or 7 months for the prior- 
ity A and B features -> tape-out end 02/94. This is a sanity check for the schedules to follow. 

Resources available for the design and inq>lementation are 
Rakesh, Sagar, Dwarka, Prakash, Sridhar and Murali. 
Vlad and Sasha are working on the new features and dieir architecture. 

PLAN FOR THE AmVITTES 

NOTE : Some percentage (not more than 25%) of time Sagar and Sridhar will be supporting 
6225/6235. 
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PLAN WITH NEW FRATIIRFii IN PAR AI.I.F.I. 
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Qtffl: 1 . Assumes a new hire (junior design engineer) in mid August *93. 

2. Bread-boards and development activity are needed for shading and dithering, live video and cross talk reductic 

3. We may need help from Dayakar*s group to convert 6440 shader to Foster City methodology. 
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Definition Issues: 

0. Decode all 32bits of CPU address or only 24 + Hi/Low MEM as Alpine ? 
Saves 6 pins which can be used for h/w configuration without external pull-ups 
or 24 bit TFT panel support 

1. High resolution panels 800x600 and 1024x768 support? TFT or STN or botii ? 
2. 16bit wide video memory support at the first tape-out? 

3. pa bus BIOS support by Nordic- IM. 
4. 90C24 pinout compatibility. 

5. Office Environment Dual Display support 

6. Video Port support was dropped. 

7. Scaling and Intopolation for One Pak and live video. 

8. Live \^deo l^dow Specification. Can we set a restriction of alignment over 8 pixel boundary? 
Can we program the live video window as a CRT-address-range ? If two windows overly, have 
the driver modify the live video window address range? 

9. HAV Icon: is vertical icon string good enough? 

10. Grey shade nu^ping option ? 

11. 24bit TFT panel support with 18bit RAM. Is tfiis OK? 

12. STN panels Cross-talk reduction on an external chq). 

13. Live Video Compression chip on a PCMCIA board 
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Cirrus Logic, Inc. Confldential Information 

LIST of NORDIC-IM Activities as of lOnQ/93 (mnrked 11/4/93) 



done'> I . Half Frame Buffer 3W SgK 

done'> 2. 32bit VL and PCI bus 3W PP 

60% -> 3. 4bit/pci packed 2W DP (not verified, needs set-up from Submarine) 
done'> 4.WavcPort 4W RB#n^MR 

40% 5. High Rcz Panel support & New Panels & lOfUM wide fonu SW SdK 

(text is done, graphics 4bit/pel and 8bit/pel started No 16 and 24bit/pel 
Do we have to do graphics expansion?) 
30% 6. WavcPort, 32bit bus, HFB and High Rtz Panel Suppuii luitgiaiimi 

3W 1 W DP with help from RB. PP and SpK 
7. New Shader & Panel Improvements 2W SgK and SE 
50% 8. 50MHz VL bus 2W PP (in progress) 

9. MCLIC TiLU. RaiiUL / 542 9 Sluuliilli i S L DLT UmaadLA 4 W PP ain f^g^f 

Sub-total #1:#9: 27W and 35MW 

10. H/W Icon + its integration SW PP 

10. Motion Video Architecture with Video Port, Play-back and Sashapack 

a. Window Conm)l, Addressing, FIFO & Scan Line Replication 6W RB 

b. YUV.>RGB 2W SdK 

c. Horizontal Zoom with average/interpolation & b,c iniegr 2W SdK 

d. . 8b/pel RGB and 16b/pelRGB IW PP 

e. 4:2:2 YUV (16b/pel) and 4:1:1 linear (12b/pel) IW PP 

f. SashaPack 2W SgK 

g. Video Port from Feature Connector, TFT panels only & Int. 4W SgK 
Sub-total: 16W and 16MW 

11. PC90 suppuil 

50% 12. NTSC Out IW DP (top level done, CRTC modifications to be done later) 

[14.] 3V RAMDAC and CLK Synthesizer 3W FJ 
[IS.] PAD IKOS model ESJi 

Subtotal logic design group: 3W and 3MW 

16. Integration of VMA 4W RBSdK 

17. Verification and Regrcsion 4W All 
[18.] Place and Route 4WTH 

19. Testability in new modules and verification 4W MR 
Sub-total logic design group: 36W 

Total design group: 35MW+16MW+3MW+36MW=90W 

Average per design-engineer with 6 design-engineers: 90W/6=15MW/DE 

Average per design-engineer with 7 design-engineers: 90Wy7=13MW/DE 

Counting 3W in October (1 1:29), 4W in November (1:26), 4W in December (1:24). 4W in Janu- 
ary '94 (3:29), we get 15W available for work. So, there should be enough time to upe-out Nor- 
dic- IM by the end of January '94, 

Note: Orion related activity is assumed low level for the design team (AD should work and A£ 
minimum modifcations and it should woric) !! Cirrus Confldential 
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Cirrus Logic, Inc. Confldential Information 
Fi^atunK Added Since 12/20/93 



1. Self Refresh 

2. 8bit Mono TFT Support 

3. 32ICHZ Status Bit 

4. NTSC-OUT Support with Digital and Analog RGB Encoders 

5. 2070 Chip Select Decode 

6. Display Data Channel ? 

7. Memory Mapped I/O for BLT registers 

8. Clock Run PCI addition ? (I do not think we need it) 

9. Get BLT to work with the signature generator (12/1 S/93 Bemie, nice). 

10. 5429 FC timing (12/15/93, D. Kecnc or Keith) 

1 1 . Overlay support for 7 194 TV Decoder with scaling 



Features Tak en out since 12/20/93 

1. g(X)x6(X) panel graphics expansion for 16bit/pel and 24bit/pel modes 

2. Assymetric 512kx8 DRAM support 

3. MCLK Frequency upgrade at 3.3V 

4. Ikx768 panel support 

5. 5429 upgrades except for memory mapped I/O for BLT registers 

6. 12 and 16 dot fonts 

7. PC98 support beyond 5428 
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Cirrus Logic, Inc. Confldential Information 



LIST of N0RDIC>1M Activmes as of lOnom ( marked 12/10m\ 



don€'> i . Half Frame Buffer 3WSgK 
done'> 2. 32bit VL and PCI bus 3W PP 

60% -> 3. 4bil/pcl packed 2W DP (not verified, needs set-up from Submarine) 
done'> 4. WavcPort 4W RBandMR 

65% 5. High Rcz Panel support & New Panels & 10/««^ wide fonts 6W SdK&SR 

(text is done, graphics H & V4bit/pel and 8bit/pel done. No 16 and 24bit/pel) 
Still to be done: 

done - > - Horizontal Centering & LLCLK generation independent ofHSYNC 2 W 

sch entr\ -> - Vertical Centering for 800x600 and VSYNC independent 2W 

sch. entry (no progr, -> • New Dither Logic for all modes including 16b/pel <& 24b/pel 1 W 

• 800x600 panels modes sinu sei^tqf A verification 2 W 

- Orion- AD & Submarine fixes I/2W 
done'> 6. WavePort, 32bit bus, HFB and High Rci Paiid Suptiuit Lutgiatiuu 

3W IW PP with help from RB. PP and SgK 
30%- > 7. New Shader & Panel Improvements 2W SgK and SE 

done'> 8. SOMHz VL bus 2W PP (in progress) 

9. MCLIC TiLU. RaiiMu / 5429 Scuuhh^li iSL DLT UunnadLA 4W PP and SyK 

50% 10. H/W Icon + its integration S^WPP 

1 1. Motion Video Architecture with Video Port, Play-back and Sashapack 

50% a. Window Control, Addressing, FIFO & Scan Line Replication 6W RB 

40% (no prosr.) b. YUV.>ROB 2W SE & SdK 

c. Horizontal Zoom with average/interpolation & b.c intcgr 2W SE& SdK 

d. 8b/pel RGB and 16b/pelRGB IW SEA SdK 

e. 4:2:2 YUV ( 16b/pel) and 4.1.1 linuai (12b/pLl) IW SE&SdK 

f. SashaPack 2W SE&SdK 

g. ViJtu Pun fiuiu rtatuiL Cuimtttoi, TTT paiiLls mil) f 6L hit. 4W SgK 

12. PC90 Auuuuit 2WPP 

50% 1 3. NTSC Out IWDP (top level done, CRTC modifications to be done later) 

[14.] 3V RAMDAC and CLK Synthesizer 3W FT 



15. Integration of MVA 4W RBSdK 

16. Verification and Regresion 4WX6 All 
[17.] Place and Route 4WTH 

18. Testability in new modules and verification 4W MR 
done ■> a. Shader Signature Generation 

b. MVA Signature Generation 
done -> c. WavePon 

d. Update Testability in all the other modules, 

add more signals & buffer existing ones Cirrus Confidenria. 

Business Informatio 
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NORDIC.IM DeveloDment Plan as of 11/22/93 



DEC I JAN I FEB 
19.20 21 22 23 24 25 26 27 
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Cirrus Logic, Inc. Confldeotial Informatioo 
NORDIC-IM Development Plan as of 12/03/93 



JUL 



-I 



RB 



SdK 



SgK 



PP 



DP 



VB 



MR 



SE 



TH, 
RZ 



Va: 



pin- >ul 



Arc) I. 
Spe< 

Sut T 



2 1 



»anc 1/Sh idcr f CI TG TX T-E! CP. 



I Toni r. E kh. U In «gr 



Tl 



Tl 



I'WF MNG. 



A rc) Iteci ure 



Tt 



AUG I SEPT 
23456789 



Sell 



»CI 



Shad( 



Pro 



. L< Id 



Ini egraticn 



Bib. 



& ( usu m ( RT : & 



$ha ler 
OR tOMClU NMit Critica 



rtodi . 

SptL Rdgistir Sd«c, Design Verif catiii 




»FB 



: 2bi i bi s 




Iniegi 



FIF>s 



OCT I NOV 
10 11 12 13 14 IS 16 17 18 



DEC 



JAN 



W ive >or & 



Sajha] 



& Veiif. &Edv. 



Paihcs 



ack D( mo 



lM1>AC»Sy II 



PucIS 



S iba ar. ! Ehadi r S ifR Kf 



] tegi Eter 



nt 



&32titfaus 



&]OdF>nt 



)/wi;on 



&ln 
(&2 



Vaa tion 



VfVAD<$lga 



Sut maipne 1 



Die 



SLMTit 

no rcc( dc) 



& ^eg -ess on 

VfVy.DaUllath 



Cus om I iod lies 



estiiiaU 



k Cc L C< ny 



CeUt,Mxles 



5PI0E,Iad-1Unt 
Prcl jiL I outi ng 



»izc 1 sttn au 



19 



<»>FoUcays 



NISC Oul 



Teite >ilii 



HUtes.]toc D tlL k Vorif. 



20 



fliFezSpec 



21 



VP)rt 



frojn F( Ir 

Vac 



Sp< cd 



It F|or rianlVac 



22 



Vac 



Va< 



Vac 



23 



24 



Int. 



Virif. 



[nt( .gr 



V^erific 



Iitgr 



25 26 



Ve if.* 



MYA 



4k Virif. 

V( rif. 



esiabi 



FEB 
27 



llty 



Veihf. 
V^etiflc 

!10i|to<G, ll-O. 



ntegr. 



Scl edu ed 

T.C. 
01/}1/S4 



28 



Cirrus Confldeotial 
Business Information 



Nordic- IM Product Implementation Plan rev.lO 12/21/98 



Cirrus Logic, Inc. Confldential InformaUon 



NORDIC-IM D evelopment Plan as of 12/10/93 



JUL 



AUG 



SEPT 



OCT 



NOV 



RB 



SdK 



SgK 



PP 



DP 



VB 



MR 



SE 



TH, 
RZ 



Va 



pin- )ul 



2 1 



Tl 



: >anc l/Sh idcr f CI TC TX T-E: CP. 



Zon\ r. Eih«ain «gr 



ScHSl 



Tl 



&12 



I WF 



A ret iteci ure 




Pro 



>CI 



Mrrc. 



St\tM 



Ini egi Eiti( n 



& ( list im < RT : & FIFO-f 



modi: 

Spe4« R^istfr S^ec, t>esiin \ erif catiii 



CJ^N^rdlsCrtka Paihes 



:2bitbis 



FC 
PlnScan 



ftpinolit i^ rsg 

Gut 



10 



\^tve »ort 



Im eg, 



W ive >or &PC 
i^egi~& Vejif. 
Sa< ha] *ac| D 



11 



12 



HtghRci 



4l7pfk. 



kRlMl >AC»Syil 



13 



14 



ParelSipp 



lit 



tegi Eter 



&32titbus 



D< UK 



IS 



IS 



Istcn M\ 
Addi 



Paikds 



&]OdFmt 
Orio I Tcs t 



Si bnu r« St adc * 



16 



£xp4 [DIt L 



&ln 



(& leode) 
Vaa tion^l oUdays 



VfVAD^siga 



Hi] tcs. I anc 
Satlmai inc 1 .0. 



Die 



17 



M\ A: i :on rol VfVA In 



"ess, 
ScanLn 



& ^eg -ess on 

\fV> . Dab iVth 



>PIi:£,F 



E^el m. F outj ng 



iize 



Anaog3K& 
EStli wte 



18 



fifc>rd sT 
Rc»Uc 



b Co L C( DT 



CcUi»M>dcs 



Cus omilod ties 



^EC 

19 20 21 



JAN 



Slu 



NISC 



Te;ta)ili 



lUnf 



istinau 



ler 



Set net 



Oul 



tUBezSpec 



A Qau 

Pat] 



VfV^ d4u Hatli 



22 



Vac 



Va( 



Vai! 




Sp<ed 



23 



Inti !gr. 



24 



i:Vurifj 
Verific 



25 



Ve If. 



26 



FEB 
27 28 



MVA 



est abi 



& Veiif. 
Veiiflc 



(01 



I itgr 



TO 



V rif. 



ity 



G,I 



,DI C j 



Sol edu ed 

T.C. 
01/J1/S4 



nte ir. ! 



rif. 



O. 
T.O 



Cirrus Confidential 
Business Information 



Nordic-IM Product Implcmcntaiion Plan rcv.lO 12/21/98 



Page 13 



CL 157995 



Attachment C — Exhibit List 



***19920803: News Release from Dialog. Pixel introduced CL-PX2070 and CL-PX2080. Exhibit EX- 
304. 

*** 19930915: Fax from Dickinson to Fujii of Cirrus Japan providing slides about Alpine Mulitmedia for 
NEC. 

***19930915: Agenda for meeting with NEC. Nordic Discussed. Meeting appears to be at Cirrus. 

***199310XX: Computer Design Article on introduction of PX2085 Media DAC. 

*** 1993 1 102: Meeting with Apple. Reported in Memo from Bob Conner to Del Mank et al. EX-543C. 
Apple "expressed interest in the Nordic Controller." CL 1600 10. 

***19931216: Power Point on Flat Panel Products. IBM Power Personal Systems (Location???. (Live 
Video Through the Host Bus— CLl 58886). PCMCIA card interface to video over bus. 

*** 19940106:. Request for price quotes from IBM Japan. 

*** 19940107: Memo from Bril to Cirrus Japan answering technical questions on Nordic, 

*** 199401 14: Memo from Bril to Cirrus Japan answering technical questions on Nordic. 

***19940114: Dickenson Price Quote on Nordic to IBM Japan. RX-553C. CL159503. 

*** 199401 18: Memo from Bril to Cirrus Japan answering technical questions on Nordic. 

*** 19940122: Memo from Bril to Mary Johnson and Brian Howard at Apple showing questions about 
VB-Nordic-APOOl. RX-567C. 



1/9/1 (Item 1 from file: 621) 

DIAI,OG(R)File 621:IAC New Prod . Annou . ( R ) 
(c) 1996 Information Access Co. All rts. reserv. 

0334800 
News Release 

DATELINE: PLANO, TX August 3, 1992 WORD COUNT: 1467 

CIRRUS ZiOGIC, Inc. 
3100 West Warren Avenue 
Fremont, CA 94S38 
510-623*8300 
Fax: 510-226-2240 

EDITOR CONTACT: 

Connie Duncan (510)226-2346 

Joe Fowler (510)226-2239 

I^imI^I^SiST^^^ breakthrough family of video chips for 

PLANO. TX. August 3, 1992 -- Pixel Semiconductor, Inc., a 
•ubsidlary of Cirrus Logic, Inc., (NASDAQ: CROS) today introduced rh« 
CL-PX2070 and CL-PX2080, companion high^eifor^ance i^tejrlted 
circuits that process and display multiple streams of full -motion 
?hf*?L P«?7o'?o*^ computer and video teleconferencing applilatrSns. 
The CL-PX2070 is a programmable digital video processor (DVP) that 
captures stores, processes, and routes multiple streams of full- 

t^rdiliLS:^""" MediaDAC (TO) chip is the indSst^' s only 
,4^*5*^^^ Simultaneously displays graphics with 

multiple independent streams of live video, allowing Gsefs to view 

SindSSS^^ " '"^^y " todays graphics -based 

Th!?* P'^o^'i'^rthe same powerful video processing technology 

harL.~ available only with complex. Expensive 

hardware. They offer users all the advantages and capabilities of 
triSI inl^r*'?"" a digital format. Thise include the fJexibility 
to add and overlay graphics and text to video sequences edit between 

mu?f ipirwTndoi^" "^n*"" r''*''*' " dispW t"s dft" 

multiple windows all in real time. This level of functionality 

"^!i?^!meSia^^n^■"""° "'^ CL-PX2080. is ideal for a range o "^' 
multimedia* applications. 

The CL-PX2070 can be used with such VGA graphics controllers as 
Cirrus Logics CL-GD5422 to provide cost-effective. yerpowLfCl VGA 
PX2080^tS'"fh,t"'' playback systems. Implementing theCL-PX2C70 and CL 
PX2080 together supports high-performance (1024-by-76e-pixel) '--e 
sv«Lr authoring, video conferencing, and video teleconf erencino 

"Market research estimates indicate that by 1996,5.7 million units o' 
Ir^i;r?^'°" "^"I'o-^Pable PCS will be shipped, representing a 
dramatic increase over current demand,- said Jim Fontaine. President 



ATI023293 



of Px?cel semiconductor. "With the price/performance solutions offered 
by Che CL-PX2070 and CL-PX2080, full-motion video capabilities wil' 
be propelled into the mainstream.- 



CL-PX2070 Digital Video Processor 



advanced digital video processing 
capabilities and features required to support and manage multi -stream 
video. It accommodates applications that require several concurrent 
video and graphic sources by providing four input/output (I/O) ports 
that can connect directly to multiple independent ino devices, 
including the host system. Two of these ports can receive video from 
^ie^"*"Lf"Y f''"^'=! supporting a variety of data formats such as 
NTSC or PAl. (the U.S. and European television standards) YUV-encoded 
data, or red, green, and blue (ROB) data. The third port interfaces 
to the h08t •yacem through the Industry Standard Architecture (ISA) 
bu. or Che Micro Channel Architecture UcA) bus. The fourth Lrt 
connects to a video memory buffer. ^ 

h? °^ multiple streams of data, the CL-PX2070 offers 

^i^^ifff^^^S*^ between its ports and internal control and 

£f2f??*^"' functions. These features enable the chip to process and 
^^^^^^^"•^"■i^ digital video it receives from% decoder "nd 

. S/^*"^ •yatem to any connected device. For example, signals 
^r?K! ^ " immediate display and 

Sev^L'^d'cIpc'ure"'* ' " ^"P^""'" simultaneLs^iSL 

Programmable Filters Perform Conversion and Provide Better Imaaes 

different formats of various I/O devices, the CL- 
PX2070 features a programmable arithmetic logic unit (ALU) that 
?he SJS'eSiii^*!"*?""'^ line interpolatiS? and fonl^ conversions, 
for JS;oo!S2^i?3.i"?^*'"*'*""? filtering and scaling functions 

tor mapping video to a particular window size or to the format 
required by an I/O device. With che CL-PX2070-S sc!lln| ca^Sility 
s^tLr^i:^^''?!?.^^: MTSC-size frame can be resized dlwn ?o tRe^' 
t^i vf^fS^S Interface Fon«at (CIF) video standard for outputting 
con?ralf^«^if device . Conversely, using the CL-PX2070's scaling 
deSo™rf.-?«r"i." ''"*" f"""" " enhances videl 

crIate"2Si«i...^Ii"^ "?^'"«'.""'T'»^"^«" oP*"" " 

prSeiSe S^r^i^tS bfJnj!ioli;fnri^:g«' '^'^ " 

Memory Management and Editing Features Support Advanced Applications 

PX20?0^fiftu«2'.i'"'2^''^''^..*?^'=^"3.»"'* ""^"9 functions, the CL- 
multiDlf i^-!! S buffer controller that can hold 

bvtei^to ITttt- "'^'^'^ capacity that can range from 256K 

bytes to 8M bytes of DRAM or VRAM, the frame buffer controller 

"?!S:'"i5^r^.?^l!r controllers, which atlowrstoJlgl of two 

Tht^ ...l^iK*? '^'?""" ^^'^ renditions mixed with graphics and text 
3idlo i'^' retrieve and transmit multiple streams of' 

-ufSor?2„ -i^ • ^«*'^uf« that is important for video 

authoring, video editing, and video teleconferencing applications. 

I5d ovMSriM.^i"!! • ^"""y °^ ^ideo transition 

ana overlay effects. Video streams can be transitioned using modes 



ATI023294 



thai- include fades, wipes, blends, or cuts, into a second video 
scream or mixed with text and graphics to give users advanced editing 
capAbiXicias. By programming the chip's overlay controls, images can 
be superimposed to create special effects. For example, particular 
images can be isolated and blended to provide a "weatherman effect," 
as seen on television weather reports. Other special effects 
functions the CL-PX2070 performs include flipping and mirroring 
images. 

CL-PX2060 MediaOAC Chip 

The CL-PX2060 augments the CL-PX2070 with advanced features and 
capabilities that include a 24 -bit digital -to -analog converter 
(I?AC), two sets of color look-up tables, digital mixer, video 
window zoom hardware, color space converter, and a hardware cursor. 
It features two input porta, one for full -motion "live" video and one 
for graphics data, and an output to drive the CRT. The live video 
port accepts either YUV or RGB data. The graphics port accepts RGB 
data only, supporting standard 8-bit VGA or 8-, 16-, 24-bit data 
through a 32- bit parallel graphics port from the system graphics 
controller, such as a Super VGA or XGA graphics controller. The CL- 
PX2080 connects directly to the ISA and MCA bus for initialization 
and control by the host CPU. 

Running at clock speeds of up to 65 MHz, the output of the CL- PX2080 
easily accommodates the update rates of full-motion video and high- 
resolution color graphics on non-interlaced CRTs at resolutions of up 
to 1024 X 768 at 72 Kz refresh. It permits the system to use a 

COMPANY: Pixel Semiconductor 

Cirrus Logic 
PRODOCT: ICS by Function NEC (3674199) 
TRADE NAME: CL-PX2080 NediaDAC; CL-PX2070 
EVENT: Product Design 4 Development (33) 
COUNTRY: Texas (1548); TX (1548) 
SPECIAL FEATURE t Price 
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CIRRUS LOGIC 

FACSIMILE MEMORANDUM 



EXHIBIT 

M-541 ^ 



To: Kimio Fuji 

Cimis Logic K.K. 
Fax Nbr: 81-3-3340-9120 

From: Bob Dickinson 
Fax Nbr: 510-226-2250 

Subject: Alpine Multimedia 

Date: September 15, 1993 

cc: Bill Chu, Jeff Diamond, Bill Knapp, Tony Man, Takeo Wada, Brent 

Wientjes 



We did not have time to cover our multimedia integration plans for Alpine with 
NEC in detail. Please convey the attached material to Onodera-san and Mino-san 
and let us know if they want to discuss this in more detail. 



Best resards. 



Number of pages, including cover leaer 10 
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To: 

F t uni : 

Subject: 
Dace: 



jdmio Fuji 
Cirrus L^ffic K.IC. 
81-3-33AO-9120 

Bob Diclcifison 

>k.1pine VlultlxnedlK 
Septemt>er IS, 1993 

BlU CHu. Jeff Dimmon^^. BiU ICnapp. Tony fvtaji. 
Wientjes 



Talceo Wad*. Brent 



V^'e dlo noc hiave time co cover our multlxnedia intesr«cion pLaxis for A^lpinc wiUi 
ZsTEC: in deull. Klease convey Uie ■.tcactied maceriai to Ono^erm-aan and Nfiro-saxi 
and 1st us Rnow if U^ey want to diacusa tKis in more detail. 

Best ref^arrdit. 



■J umber of pac««. •ncluctn^ cow tcav lO 
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THIS DOCUMENT (REDUCED SAMPLE ABOVE) 
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AGENDA 

MEETING 
September IS, 1993 
9:30am - 12:00n 




Introduction 



Cirrus Logic Overview 



NEC Requirements 

Media Manager™ Demo 

542x/Alpine/Northstar Roadmap 

64 Bit Architecture 

Multimedia Integration 

Nordic 

Wrapup 



Dickinson 

NEC 

Brasfield 

Man 

Chu 

Wientjes 

Talreja 

All 
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AGENDA 

September 15, 1993 

1 . Price Projection for GD5428 in Q1/Q2, 94 

2. Production Status for GD5428 

(1) Current Production Volume 

(2) Current Lead Time 

3. Manufacturing Status 

(1) Wafer Fab. Site 

(2) Assembly Site 

(3) linfiuence of Simitomo Explosion 

4. Sales Status for GD5428 

(1) Sales Volume 

(2) Major Users 

5. Cirrus Financial Status / Q3/Q4 of CY93 

6. Questions for Cirrus Products 

(1) Alpine Availability 

(2) Future Plan of Cirrus Products After Alpine 

(3) Future Possibility of Adopting 32Bit Memory 
Mapped Register 
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CIRRUS LOGIC 



INTERNAL MEMORANDUM 



To: 


Eve Brasfield, Bill Chu, Jeff Diamond, Tony Man 




Prem Talreja, Brent \^^entjes 


From: 


Bob Dickinson 


Subject: 


NEC Agenda 


Date: 


September 14, 1993 


cc: 


Doug Bartek, Del Mank, Keith Uhlin 



Attached is the agenda for the NEC meeting tomorrow. Your time budget is noted in 
parenthesis. The meeting will be held in the Sales conference room. 



Let me know if you have any questions. 
Best regards, - 

'St 
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C/RRt/S LOGIC 



INTERNAL MEMORANDUM 



To: 


Eve Brasfield, Bill Chu, Jeff Diamond, Tony Man 




Prem Talreja, Brent Wientjes 


From: 


Bob Dickinson 


Subject: 


NEC Agenda 


Date: 


September 14, 1993 


cc: 


Doug Bartek, Del Mank, Keith UWin 



Attached is the agenda for the NEC meeting tomorrow. Your time budget is noted in 
parenthesis. The meeting will be held in the Sales conference room. 

Let me know if you have any questions. 



Best regards. 
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AGENDA 

NEC MEETING 
September 15, 1993 
9:30am - 12:00n 



Introduction 




(10 


mins 


Cirrus Logic Overview 


Dickinson 


(10 


mins 


NEC Requirements 


NEC 


(10 


mins 


Media Manager™ Demo 


Brasfield 


(30 


mins 


542x/Alpine/Northstar Roadmap 


Man 


(30 


mins 


64 Bit Architecture 


Chu 


(15 


mins 


Multimedia Integration 


Wientjes 


(15 


mins 


Nordic 


Talreja 


(30 


mins 


Wrapup 


All 
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AGENDA 

NEC MEETING 
September 15, 1993 
9:30an] - 12:00n 



• Introduction 

• Cirrus Logic Overview 

• NEC Requirements 

• Media Manager™ Demo 

• 542x/Alpine/Northstar Roadmap 

• 64 Bit Architecnire 

• Multimedia Integration 

• Nordic 

• Wrapup 



Dickinson 

NEC 

Brasfield 

Man 

Chu 

Wientjes 

Talreja 

AU 
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Inew product developments 



ICS & SYSTEM DESIGN 



RAMDAC adds video to 
PC graphics subsystems 



Designers of graphics subsys- 
tems for the PC have been ach- 
ing to add value to their prod- 
ucts. Video is the obvious answer, 
but a lack of any PC graphics/ video 
standard, and the cost of duplicate 
circuits has kept the video and 
graphics on separate boards. To 
address these problems, the Pixel 
Semiconductor subsi. iary of Cirrus 
Logic has introduced the Px2085 
MediaDAC a 135-MHz. 24-bit 
RAMDAC . which is the first to pro- 



mixing of high-resolution graphics 
and full-motion video. The YW to 
RGB color space converter delivers 
24-bit full-motion video and saves 
video memory. Look-up-tables on 
the chip allow brightness and con- 
trast control at 1280x1024 resolu- . 
tion. Other advanced features * 
include tag position, individually ' 
zoomable windows, interpolated ' 
zooming and single pixel resizing 
precision. 

More than a generic RAMDAC the 



Px2085 MediaDAC 
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PALETTE GAMMA 
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The f»x2085 Media- 
DAC is a highly inte- 
grated graphics chip 
with built-in digital- 
to-analog conver- 
sion. The chip offers 
a cost-effective way 
to add video capabil- 
ities to graphics 
boards. Cost is saved 
by allowing video 
and graphics func- 
tions to share the 
same D-A convert- 
ers, color converter, 
arid multiplexing cir- 
cuitry. (The diagram 
shows video func- 
tions shaded.) 



il 5^2X8 
I { CURSOR RAM 



512XS 
CURSO»^ RAM 



i i ^1 j i II j i OAC ( OAC I DAG It 



51 Ir 



i L 



vide video-ready functions and VESA 
Advanced Feature Connections 
■ VAFC) compatibility on a single chip. 
The Px2085 MediaDAC offers an 
easy design transition for board 
designers interested in adding 
video-ready functions to their graph- 
ics boards. Pixel's strategy is to let 
the video and graphics functions 
share the same D-A converters, color 
converter, and multiplexing cir- 
cuitry. 

The CI.-2085 supports four full- 
motion video windows, which can be 
independently occluded. The 
MediaDAC enables the full digital 



MediaDAC is a highly integrated 
graphics chip with the digital-to- 
analog conversion built-in. The 
MediaDAC comprises six functional 
blocks: a host interface unit (HIU). 
video processing unit i\TU). graphic 
processing unit i GPUj. cursor border 
control unit (CBCU). overlay control 
unit (OCU), and monitor interface 
unit (MIUI. 

The HIU connects the MediaDAC 
directly to ISA and MCA buses. Elim- 
inating costly interface glue logic, 
the HIU decodes a 16-bit address and 
responds as an d-bit peripheral. The 
HIU also interfaces with hardware 



on-board. Through a 32-bit data 
bath, the VPU inputs digitized RGB 
and YL^ video data from a wide 
range of formats. The VPU handles 
such functions as zoom control, for- 
mat alignment, chromiance interpo- 
lation and color space conversion. 
The VPU contains a programmable 
gamma corrector lookup table. 

On the graphics side, the GPU 
accepts graphics data through a VGA 
interface or from VRAM As a result, 
the MediaDAC can support the large 
installed base of 8-bit serial VGA 
hardware and VGA^ompatible soft- 
ware, while at the same time sup- 
port next-generation systems that 
need to read from a 32-bit VRAM 
serial data port. 

The MediaDAC implements a 
three-color hardware cursor The 
CBCU on the chip controls the cursor 
color, pattern, and position of the 
cursor. It also defines the charac- 
teristics of screen window borders. 

Video and graphics come together 
at the MIU The MIU contains cir- 
cuitry which the video and graphics 
both require to get onto the screen. 
These include three video-speed 8- 
bit DACs. internal comparators that 
provide sense function and synchro- 
nous alignment logic. 

The MediaDAC is register compat- 
ible with Brooktree's popular Bt485 
RAMDAC and will interface with all 
video cards that implement the VAFC 
standards. The chip is packaged in 
a 160-pin quad-flat-pack. Available 
in samples this quarter, the chip is 
expected to be in volume production 
in early 1994. The price is $50 
(l.OOOsi. —Jeff Child 



MediaDAC at^ 




• VESA Advanced Fea&ffe Con^ 
neaor compatible.^ ..^^im^; 

• 135 MHz pixel dock fates.' 

• Supports wide range of RGB 
and YUV video formats. . 

• Supports graphics input from 
VGA or VRAM- 

• 64x64-pixel hardware cursor. 

• Direct interface to ISA and MCA 
bus. 



Pixel Semiconductor/ 
Cirrus Logic 

3100 W.Warren Ave 
Frecmont, CA 94538 
(510) 623-S300 
arde246 
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To: 


Del Mank 


Mail Stop: B2-o33 




Mike Callahan 


Crystal Fax #512-462-3352 




Tim Blankenship 


Crystal Fax #512-462-3352 




btevc Bily 


Crystal Fax #512-462-3352 




Lnns Luaden 


Crystal Fax #512-462-3352 




Sunder Velamun 


Mail Stop: B2-541 




Peter Pranys 


Fremont Sales Office 


cc: 


Bill Chu 


Mail Stop: B2-630 




Doug Bartek 


Mail Stop: B2-630 




Mike Kabealo 


Mail Stop: B 1-7 10 




Dan Hauck 


Mail Stop: 81-706 




Bill Caparelli 


Mail Stop: 81-700 




Bob Dickinson 


Mail Stop: 81-902 


From: 


Bob Conner 


Mail Stop: 82-541 


Subject; 1 1/2/93 Apple Meeting 


Date: 


> November 11, 1993 





EXHIBIT 



RX 



-543 C 



Executive Summary: 

During the LCD Drivers* Strategic Plan presentation last month, we discussed the need for the "OEM 
pull-through strategy" execution to create a demand for our LCD drivcrs (via getting major systems 
OEMs to ask their vendors - our customers - for LCDs using our drivers). On 1 1/2/93, we discussed 
our LCD driver products (under N.D. A.) with Apple's Portable Display Engineering and Advanced 
Display groups. The meetings were very successful! Highlights: 

■ Portable Display Engineering has RFQ's out to all major LCD vendors for: 

- 640x480 256K color TFT LCD (production in 1 0/94) - highest priority 

- 800x600 256K color TFT LCD (production in 10/94) 

- Apple would like to be the first notebook OEM to offer a notebook with this 
LCD; however, it's lower in priority than the 640x480 LCD. 

■ Portable Display EDgineeriog liked our Peanuts driver and will contact their vendors 
(Hosiden was spectflcaUy named) regarding availability of a Peanuts-based LCD! 

■ Advanced Display is exploring developing a 1 2" 256K-16.7M color TFT LCD monitor product, 
which must be priced <53.000. The mass production timeframe (e.g., CY '95 or CY '96) is 
dependent on Apple obtaining a color TFT LCD cost enabling hitting this price point 

■ Advanced Display liked the Woodstock/Snoopy feature set, particularly color matching. They 
arc interested in woriung with us to resolve the LCD module interface bottleneck. 

■ Advanced Display wants to discuss with Cirrus Logic an idea that may significantly increase 
graphics performance. (Apple wants to employ this idea first in a CRT-based product). 

Anachcd is an ad for the new PowerBook Due 270c. which features "16-bit color - an industry first." I 
believe this notebook uses Sharp's 1 8-bit color TFT LCD (although we did not discuss this). 

I would like to thank Peter Pranys for setting up these visits. We should plan to visit additional major 
OEMs, particularly once we receive a Peanuts-based LCD (expected in 1/94). 
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Mftodkiff^ tbePMrBook Duo 270c 



The ne* Apple' f\)swBook Duo' 270c ar^ 
Pcwt6oc4( Duo 250 may be tw of the lightest 
rxxebook .owTiputere you can buy today B^^ 
didn I Slop us from gNing voj the wo^ 

Theyre surprisingty brighu remartaWy com- 
fcnable. and ihey run longer than jusi about 
any other ftM^rfiook! Without compromising 



on powec speed or expandability. 

At a mere 42 pounds, the sleek 
PDwerfiook Duo 250 is the lightest 
notebook you can buy with a back- 
lit, active-matrix dispby. DeiivOT^ 
sharp, presentatxxH]uality images. 

Not to be outdone, the 



45-pound POtt«fiook Duo 270c is the 
first notebook under 5 pounds *iih a 
backlit. actrve-mairix cok)r diSDb\. 

s only notebook compuipr irT^, 
vary weigh! dass to provide stunning. 
|) 16-bilcok)tWhxh happens to be ay 
new standard for the Wusirv. 
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Meetings' Details: 



Apple has three groups which are currently evaluating LCDs: 

■ Portable Display Engineering: evaluates/selects LCDs for Apples notebooks 

■ Advanced Display: evaluates/selects non-CRT display technologies for the Imaging group, 
which makes monitors, printers, scanners, etc. 

■ Newton: evaluates LCDs for PDA's. Diannc Colbert is the single display engineer. 

Customer: Apple Computer - Portable Display Engioeering 

Date: Tuesday. Nov. 2, 1993 

Attendees: Tom Credelle, Manager. Portable Display Engineering. Apple 
Steve Baily, Apple 
Peter Pranys 
Sunder Velamuri 

■ Submitted RFQ's out to all major LCD vendors for: 

- 640x480 256K color TFT LCD (production in 1 0/94) - highest priority 

- 800x600 256K color TFT LCD (production in 1 0/94) 

- Apple would like to be the first notebook OEM to offer a notebook with this 
LCD; however, it's lower in priority than the 640x480 LCD. 

- Said that this resolution fits Apple's system architecture, which already uses 1 
MByte of video memory. 

■ May consider a 1024x768 TFT LCD with a digital interface for CY '95 notebooks. 

■ Expressed interest in the Nordic controller. 

■ Apple's application software has both a 15-bit/pixel mode and a 24-bit/pixcl mode. 

■ Liked our Peanuts driver and will contact their vendors (Hosiden was specifically 
named) regarding availability of a Peanuts-based LCD! 

■ Suggested that we discuss Peanuts with OIS (said Chuck Wilson is a key Program Manager & 
Rex Tapp is the President). 

■ Liked the Woodstock/Snoopy features. Said that an upcoming Apple product will have the 
capability to adjust the contrast ratio/viewing angle via software (not hardware). 

■ Currently drive the LCD at 60 Hz (no CRT timing - no horizontal & vertical blanking), 
because for "simulscrecn" (i.e., simultaneously driving two different displays with the same - 
or different - images) currently use two separate graphics controllers and video memories. 

- However, in the near future Apple may eliminate one of the video memories to 
minimize cost, which implies that driving the LCD with CRT timing for "simulscan" 
may become important. 

■ See 1 024x768 color TFT LCDs moving rapidly into overhead projectors. 

- With their current implementation using two separate graphics controllers & video 
memories, Apple can easily simultaneously drive different resolution LCDs (i.e., a built 
in 640x480 LCD and an external 1024x768 LCD). However, a problem will occur if 
they eliminate one of the video memories. 

■ In response to our Peanuts roadm^, said that 

* ^ LCD using a 6-bit driver and 1 -level frame rate modulation will have acceptable 
display quality. 
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. A horizontal-stripe LCD has inferior display quality relative to a vertical-stripe LCD 
according to some human factors studies. Suggested that we contact Jim Larimer at 
NASA-Ames for some details on these human factors studies. (Said that OIS uses 
quad-green). 

■ Both Tom and Steve travel to Japan to meet with display vendors once per quarter. 

■ In some casual conversation over lunch, Tom expressed some disappointment with Sharp's 
"lack of responsiveness'* regarding developing new TFT LCDs to meet market requirements. 

Customer: Apple Computer — Advanced Displays 

Date: Tuesday, Nov. 2, 1993 . 

Attendees: Neil Bergstrom, Manager, Advanced Displays, Apple 
Dick Cappcls, Display Engineer, Apple 
Peter Pranys 
Sunder Velamuri 

■ Advanced Display is exploring developing a 12" 256K-16.7M color TFT LCD monitor product, 
which must be priced <^3,000. The mass production timeframe (e.g., CY *95 or CY '96) is 
dependent on Apple obtaining a color TFT LCD cost enabling hitting this price point. 

- Said that Apple will only introduce a new product if it's priced low enough to be high 
volume (i.e., Apple has no interest in serving niche markets). 

- Looking for ways to not only equal, but to exceed the CRT in order to justify the LCD's 
price premium. 

- Said that vendors will soon be achieveing two 1 2" LCDs per motherglass. 

■ Advanced Display liked the Woodstock/Snoopy feature set, particularly color matching. They 
are interested in working with us to resolve the LCD module interface bonleneck. 

■ Regarding the LCD module interface, 

- Typical cable length is 1 .75 to 1 .9 meters. 

■ Advanced Display wants to discuss with Cirrus Logic an idea that may significantly increase 
graphics performance. (Apple wants to employ this idea first in a CRT-based product). 

■ Advanced Display is also studying non-LCD flat panel technologies: 

- When asked whether we are actively participating in the ferroelectric LCD market, I 
responded that wc arc working with Clanon (the implication was with controllers, not 
drivers - Apple understands ferroelectric LCDs are digital and create gray scales via 
error diffusion dithering). Apple seemed to think that ferroelectric LCDs are priced 
aggressively relative to TFT LCDs. There may be some opportunity for Northstar here, 
which requires some follow-up. 

- Said the Nippon Denso has developed an anti-ferroelectric LCD 

. Said that Fujitsu is making great progress with color plasma panels and the prices will 
decrease significanUy in CY '94. 

- Looking at FEDs 
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Action Items: 

■ Send Dick Cappels infomation on Crystal's SmartAnalog f AR: Sunder/PeterV 

■ Provide a Snoopy & Woodstock spec to the Portable Display Engineering and Advanced 
Display groups after Fall Comdex (AR: Sunder/PeterV 

■ Get a mutual N.D.A. established with Apple's Advanced Display (AR: PeterV 

■ Set-up follow-up meeting with Apples* Advanced Display to: (AR: Peter) : 

- Hear Dick Cappels* idea to significantly improve graphics performance. 

- Explore whether Apple is interested in a controller that supports ferroelectric LCDs 

■ Set-up meetings with the Portable Products Engineering, Advanced Display and Newion groups 
to demo a Peanuts-based LCD - hopefully in 1/94 (AR: Peter V 
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'CIRRUS LOGIC 

MEMORANDUM 



December 20, 1993 

To: John Carlisle 

cc: Bob Conner 

Prem Talreja 
Mike Callahan 

From: Del Mank 

Subj: IBM Power Personal Systems 

Attached is the presentation material used during our meeting on December 16, 
1993 with IBM Power Personal Systems. The Woodstock information is all 
covered under NDA and is designated as NDA material on the attached copies. 

Please forward to the appropriate IBM personnel as pan of our follow-up. 




attachment 
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Date: 



FACSIMILE COVER SHEET 

1 A /'-] H 



Attention; l>jr> 



Company Info,: 

FacsinulcNo.: fl^' - H'T ^ 

From: H V /V 1 1 J'lN^A • 

Re: 1 



Conusents: 



SCV 3y:CIRRUS. LOGIC OPS : 1- 5-«* : 8:21?" : 813i3iC9120- CIHRUS lOiiZ OPS:« i 

I RX-552 C_/ 



^CIRRUS LOGIC V 



CC: 

NomberofPages (Including Covtx Letter) ,S • 

Shiiuiiku GfMD Tower BIdg. 26F 
6-14-1 Nisfai-shizuuka, ShnyulcD^ Tdcyo 160 
Telephone 813-3340-9111, Fax 813-3340-9120 

Cirrus Confldcotial 
Business InformatiOD 



CL 159497 



RCV SY.:CIRRU5. LOGIC OPS 



ei333iC012C- 



CIRRUS :OQIC 0C5:i 2 



To: MX — IBMMAIL 

cc: JLieoee — vmtvn^ 
Subject: Unci: Nordic 
Sensltlv^ity: — 



Kflgowa, S«to6hi 



Uncloaairied 



NAKAZA 



Naicazawa, Vutcxfuaa 



From; 



Arimaaa Naltoh, 



81 (Japan) -Mfle-73-aiiO or 2H72 



Mr. Oicklnson, 

rnanK you very aucft for your prasentation of your video chip Mordic 
and also rood nap of your future video laplaiientat lone. Although 
I have not fully underatood your future plan on aultl-mdla support yet, 
I fiff) eure that I aa intereitea in your Nordic for our g/9^ product. 

Me have carefully reviewed the specif Icetlone end avallaDlIltlea of 
Nordic, and I nave the following requeate for «e to coneioir tne Noroic cn 
In our product in fiore serious m^nuT. 

1. Price Inforaatlon 

Please provide Price inforaatlon in the yearly quantity of 50K - 
lOOK range. 

2. Availability of aaapiee - to oe laproved 

Me woulo need the eenple of our engineering test (qty SO to 30) by aid 
narch and the eeaple for Systea Integration Verification Teet 
(qty 200 - 300 ceraaic pacKage) by Hid April .. If It la possible 
to get the first woricing saaples dy Hid March, schedule wise we could 
laplemsnt Nordic in our 9/9M products even it is vary critical. 

3. Perforaance 

Ham reaeon why I an intereated In the Nordic is high psrforaance. 
As I aaee tne question on the aeetlng, it is not yet lOOX clear to 
ae Why you con aeeuae saae perforaance as your desktop chip since 
I still oelelve that VRAntDRAH) is snared with fraae buffer function 
to drive tCO, and that there alght be soae perforaance degradation. 
If you provide ae any aore inforaatlon to aake as aore coafortable 
on the perforaance you are claialng, it would be appreciated. 

^. early Tveluation Board 

ir we decide to pick up the Nordic, then we would need to aake our 
BIOS reedy to test by the tiae we get your first saaples. 
Plsasa nake neceaeary errengeaent to provide us your current cnap. 
Which we were told regieter coapatlble to tne Noroic, as soon as 
possible. And also we would like request you to provide us the 
source cude of the BIOS for tne current chip for our reference. 

5. I/O decodi 

Hue to the shortage of I/O pins, the Nordic nesds external circuit 
10 decode the I/O address, wnicn could be m reason why we could not 
use the Ncrdic. Would you pieass rsconsldar the design so that ws 
Oo nut need the eiiternei circuit .... Instead we would have no 
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problea if t|ou rawov* your audio rtaturos fro* Nordic. 



rniB note dooon't iModlataly mmmnu w« oro going to uao tno Nordic 
nood gour strong support for us to natco tha asBtsBaant. Ona of nu* 
engineara s. Kagawa aant ttia list of quastion to nr. Niijiaa. Your 
P8f sonar attention to gat ua the answarc in ti»alu Mnnar would ba 
dXso appreciated very auch. 



Slncereiq 

Ariaasa Naitoh 



Regeras, 

Mai tnh 

fox 81 ( Japanj -H62-7H'»i942 
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Shiniuku Green Tow«r Bidg. 26F 
6-140 Nlshhshlnluku. Shinjuku-ku. Tokyo 160 
FAX: 8V3-334a-9120 
TEL: 81 -3-3340-91 40 



FACSIMILE 



MESSAGE 



To: 



Cirrus U»gic Inc. 



From: 



John Niijima - CLK.K 

T WuJa / Bill Knapp / Y. .Sasaki 
Kalph B;iraic ^ K. ^'ujn ' IVu *. 
TVem Tairxga / Robin Han 
liob C:o«ucr / Bob Dickinson 



Totsl Pages: 2 



Cc: 



CLKK 

Cirrus Logic Inc. 
Cirrus Lope Inc. 



Re: Nordic Qpcsiions • IDM Yanmo ^ 

Dennis, 

Kapawa-san sent inc acWitional questions on Ntiniic. I've fwcpurcd my answers Wtr Mime of 
tiicni (wrincn wirh under line*. Please review ihtwr qucKUtms unU my ans-weni. It you linu any 



h F(»r STK coiiir pnnels. NorxJic can gcocraic 4096 colors Tor icxi and 2.V>K hn jtruphic** when 
- Iri (amc x 4 dithaini?" is scloacd (^wgc ^ JUl). Why arr number ijf ctiU^rs are differeni 
btiwccn text and traphics? (NordiC vdW not use diibcnna for text moOe ) 

2) Can Nordic display Z56K colon on IKbppTKT punel (Mxm)) m inic col^ir mode? (Ycn) 
Will you pnwdc display driver for thai irnxk; (64(bi4«D04bpp)? ( Yc^ 

3) IBM will make the display unit io be upgradable frun oUcr J<S b»i DSTN punel U) l8bpp 
TFT panel. Thc\* warn to ounimue number nf «^;tkiIh nm inUi the di.^ay unit If all iM* 16 
bit jmettacc si^s tor DSVS pund are subset of 18 bit RGB edpuls fa It^pp TFT panel, 
that's pcxxJ. IBM wantsi lo know conncttion liatU for 16 hit DSTN punel and 18bpp TFT 

panel. 

4) iHM NfciM use Uxal bufi (VESA or 486 dirca) ooofiguraiitw. Is ihcre VGA disable ui 
iiddrcNK 3C3h? ^'hat ii the bit assignmcm? In there any olhcr VGA di.sable p^rtt 

5^ V()rdic will niH have ttill 32-bit iuJdrc$s bus input in ihekxail bus c*m^^ What kind 

nt address dccodci will be needed im Hf OH K4EM0RY input? 

(This IS same Lssuc which Naitoh-?*un tt<kcd u> Bob Dickinson in his l2/2yiV3 Icncx IBM 
docsn*T \A'anr to put CTtcmal dccnde logic, ii may cauue ciitical timing path and need 
addiiional board space) 

0) W Ncn will Nordic evaluaiiisi hoard be a\'ailable? What will be the price? 

7) Can N( »fdic (Hiipui victeo data stream for PALcnaxJa .'^uch a** SAA7199B? IBM ncedi K) 
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biiiJd an Eiimpcan model. 

8) E>X5 GE>S235 have similar rcpan «ct (cxcludiflg BitBLT cnpinc) to Nordic? Wtwi is the 
;iv;ul;ibiht\ ihc c\uluiuictn boanl (VL hu>)'' 

( i^.is is also mcnuoncJ in Nuiirjh-!!»an's teuer) 

**) When5iMH/ v1c:i.Ki?*asea,Tpcwill bc4<'>nit. Generally, 70ns DRAM reqiiiiw 45ns Tpt. 
Docs ir mean that Wt\$ DRAM may be ncccssiary when 5()MJ U MCLK is iwetl? 

101 lUM will us« ihe vCiA v;aniRillerai3.3V. Kt»Uic will support 65MHz VCLK at 3.3V 

vvh;u IS maxunum irct|ucm;y W MCLK ai 3-3V7 Is n aOMH/.'' it may not be kxepuiNc hx 
mw. Uissipiinuinily slt>weTman5r>MH7MCLKfcjr5Vopcni30ii. 44-45MH7. is in the 
:iLt^iahle raniic Can we ^uininiee 44-45MH7 MCLX operation at 3.3 V on Nonic'' 

Best Rtrgrrds. 
Jtihn. 
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* User name: SHAW (11) Queue: UID£SK/U\:x_-J:y.:<3: 

* File name: Server: CLr?C201C 



* Directory: r EXHIBIT 

* Description: TOSHIBAO . ■ 

* December 21, 1998 6:04Dm || 
********* ********************** *****.*****|| RX-561 O 



SSS H H A W W 

S SH HAAW W 

S H H A A W W 

SSS HHKHH A A W W W 

S H H AAAAA WWW 

S SH HA AWWWW 

SSS H HA AW W 



L SSS TTTTT 

L S S T 

L S T : : 

L SSS T : : 

L ST 

L S S T • : : 

LLLLL SSS T : : 
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Memo 

TO John Nlijima . CLKK 

FROM: VladBril - Cirrus Logic Inc. 

DATE: January 7, 1994 

RE: Questions on Nordic 

CC: Dennis Jow, Bob Conner, Bob Dickinson, R. Han, Del Mank, T. Wada, T. Ho 



Thank you for making inquiries about Nordic. 
Lately I got two faxes with questions on Nordic functionality. This fax will answer mosi 
of the questions. 

ril be glad to be of further assistance if necessary. 

ril Stan with the fax with the ref. # JN940 1 -010 of 01/06/94: 

£21: Status of every signal during suspend. 
Al: Nordic can go into Suspend Mode: 

- by pulling H the Suspend Input Pin (SUSPI) -> h/w suspend 

- by asserting a register bit (CR20[3]) -> s/w suspend 
Minimum power consumption is achieved with h/w suspend. 

By definition. Suspend is a minimum power state in which the system is not accessins the 
graphics controller or the Video Memory. 

If it is desired to put Nordic in a state in which CPU executes programs while reducing 
power consumption, Nordic should be in Stand-by mode. 

a. In suspend most input buffers are disabled so that even if the input is floating, toggling 
or in-between the rail they do not take any power. Exceptions are: the Reset pin. 

the Suspend Input Pin, 32KH2 input. 

- H/W Suspend minimizes power consumption on the CPU bus side on all pins. 

- SAV suspend leaves some pins active on the CPU side so that an 8bit I/O could get the 
chip out of the s/w suspend state. 

The way the CPU bus pins are treated is the only difference between s/w and h/w suspend 

b. In both s/w and h/w suspend most output buffers are forced L so that they do not feed a 
non powered device, like the flat-panel. 

- All outputs to the Flat Panel are forced L in Suspend. 

- We assume the Video Memory DRAM-s powered on and refreshed. Either slow 
refresh (at 8KH2) or self-refresh can be used. RASn, CASn which are togghng at 8KH2 
frequency if slow refresh is selected, as well as WEn and OEn which are H (inactive). 
Memory Data pins MD[31:0) are configured as inputs and the inputs are forced H inter- 
nally, so that Nordic does not take power. 

Please note that the external configuration Pull-Ups on MD[] pins will not take power in 
Suspend as the MD signals are floating in Suspend. Nordic MD[] inputs are internally 
forced H in suspend so that the floating state of the MD[] signals does not lead to power 
consumption. Even if we decide to drive MD(] signals H in suspend, these Pull-Up-s will 
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noi take power. The internal pull-downs on the MD[] pins are active only at reset or s/w 
switch read. So they do not take power. 

- Feature Connector Data I/O-s FCP[7:0) are also configured as inputs and the inputs 
are forced H internally. We assume that the h/w driving the Feature Connector is not pov. - 
ered during suspend. 

- FCVCLK input is forced H internally. 

- All Feature Connector control inputs like,FCES YNCn, FCEVIDEOn are forced inter- 
nally to the Slate for FCP[7:0] = input to Nordic. 

- FCBLANKn, FCDCLK. OVRW outputs are forced L. 

- If the Feature Connector is not enabled, all FC pins shared with 24bit panel pins will 
stay outputs, driven L in Suspend. 

- TV-Out outputs (CSYNC = Composite Sync, NTSC/PAL and TVON i will be driven L 
during suspend. These pins were added recently to support Analog TV Encoders like 
AD720 and MCI 377. 

- HSYNC and VSYNC signals are controlled by pre-progranruned GPMS register bits. 
This way the CRT Monitor could be in either Stand-by or Suspend. We drive 32 KHz on 
them or drive them L depending on GPMS register bits value. GPMS is the Green PC" 
specification for CRT Monitors which Nordic supports. 

- R,G.B are blanked in suspend and the DAC as well as the RAMDAC RAM are in 
power down mode. 

- Panel Power Management pins are inactive (L) in Suspend. 

- OSC (the 14MHZ clock ) input is also internally forced H in Suspend. 
Both dot-clock and memory-clock synthesizers are stopped. 

- In H/W Suspend CPU Address, Byte Enable and Command inputs are all internalK 
disabled (H). CPU Data DAT[3 1:0] are inputs and forced H internally. The CPU bus may 
be floating as far as Nordic is concerned - Nordic will not take power because of a tloating 
CPU bus when in h/w Suspend. The CPU bus Outputs RDYn. LDEVn. INTR will be inac- 
tive (RDYn =H, LDEVn=H, INTR=H if Interrupt is cleared in register CR 1 1 ). 

- In S/W Suspend CPU DAT[7:0] is active, as well as all addresses and bus command 
inputs. This allows to execute 8bit I/O commands to get the chip out of the Suspend state. 
This is the main reason S/W Suspend takes more power than H/W Suspend. 

If the CPU Bus activity is stopped or low intensity and the voltage levels on the CPU Bus 
are CMOS levels (close to the rails -VDD or GND), S/W suspend power consumption will 
be close to h/w suspend power consumption. 

Please note that Nordic actually drives low all outputs going to powered down devices, 
when in Suspend. 

Cirrus Logic Question: What is the status of the CPU Bus during suspend'? Active, float- 
ing, quiescent (no activity) ? 
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Q2: Estimation of Suspend Current. 

A2: HAV Suspend Current is estimated, in production stage to be: 

- below 250uA at 3.3V Core-VDD. with 32KH2 clock. 

- below 1mA at 5.0V Core-VDD. with 32KH2 clock, 
SAV Suspend Current is estimated, in production stage to be: 

- below 350uA at 3.3V Core-VDD.if the CPU bus is fully quiescent and ihe DC 
levels 

of the CPU bus signals are within 0.2V off the rail (CVDD or GND). 

- below L2mA at 5.0V Core-VDD if the CPU bus is fully quiesceni and the DC 
levels of the CPU bus signals are within 0.2V off the rail fCVDD or GND). 

- below 2mA at 3.3V Core-VDD if normal CPU bus activity in the system 

- below 4mA at 5.0V Core-VDD if normal CPU bus activity in the system 



It is highly advisable to have 3.3V, or even 3.0V Core-VDD at the time Nordic is in Sus- 
pend Mode. This will minimize Suspend Power Consumption. The peripheral VDD-s 
(CPU bus, panel, CRT&TV, memory) may remain 5V. 

The Suspend-Status Output (SUSPSTn) can be used by the system to know when the chip 
is in actual Suspend State. 

Please note that DACVDD-s and Clock Synthesizer VDD-s should have the iame value a^ 
the Core-VDD. at all times. 

Q3: Support for self refresh and slow refresh DRAM-s. 

A3: As in CL-GD6205/1 5/25/35 controllers, Nordic will suppon both self and slow 
refresh DRAM-s. The basic frequency of 32KHz can be derived from a 32KHz clock 
(RTC) or internally (on chip) by dividing the 14MHz signal supplied on OSC. If external 
32KHz signal is not supplied to the chip, the suspend power will be higher (bv 300uA at 
3.3 V Core VDD). For slow refresh DRAM-s 8KHz refresh frequency is used. 

Q4: Power Sequencing during transition between normal, standby and suspend modes. 
A4: 1 do not quite understand what you mean. Nordic assumes that all VDD-s to the chip 
remain ON in all modes of operation. 

If one VDD is OFF, all VDD-s should be OFF. In no mode Nordic saves power by cutting 
one or more VDD-s off the chip. 

Nordic executes by itself power sequencing to the Flat Panel when going into Suspend 
and Stand-by. Nordic also has an option to control only the Back-light of the panel for 
quick power reduction. 

Stand-by is a timer driven mode (if no Video Memory Access happened within a pro- 
grammed lime the chip goes automatically into Stand-by) but it can be also s/w or external 
input pin driven. 

It is not clear to me what you mean by "power sequencing" that leads you in and out of 
suspend. Do you mean I/O register write sequence? 
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ril continue answering the fax with ref # JN940I-015: 

Ql: Handling of Color Palette Index Register/RGB Temporary Latches/Attribute 
Controller Toggle Flip-Flop and 32bk Graphics Controller Data Latches. 
I see several related questions: 

1. Can Nordic save all this data in normal operation? 

2. Can Nordic read and write all this data during stand-by? 

3. Can Nordic read and write all this data during suspend*^ 

4. Can Nordic read and write all this data during suspend resume sequence ^ 

Answers: I. As it is now, in normal operation. Nordic: 

- can read and write the Color Palette Index Register ARX: read ai CR26. 
write at 3C0 with Attribute Toggle = 0. 1 assume you mean the 16 stage EGA/VGA inter- 
nal palette (not the RAMDAC 266 stage palette) 

- cannot read RGB Temporary Latches in the RAMDAC RAM. Our BIOS 
has a mechanism to handle this limitation in its Save/Restore routines. I asked the BIOS 
engineer to explain in detail how it is done. If what we do now will prove not to be suffi- 
cient, we could look into making these Shift Register Latches readable. I assume you are 
talking about the 6bit x 3 Shifter used by the RAMDAC RAM to accumulate RGB via V 
O before writing all 18bit of data into the RAM. 

- can read Attribute Controller Toggle Flip Flop at CR24 and write it by reset- 
ting it and than do a dummy attribute index write. 

- can read the 32bit Graphics Controller Data Latches at CR22 w ith GR4[ 1 :0] 
selecting the byte to be read. To write these Latches though one needs to write the read in 
memory and then do a memory read. 

2. Even if dot-clock is stopped in stand-by, Nordic detects a CPU access to the 
RAMDAC registers and temporarily uses OSC clock to execute the access. So. there is no 
difference in the operation from the CPU side when the chip is in stand-by versus normal 
operation. 

3. A. In S/W Suspend, we can access all registers but RAMDAC and Attribute 
Palette (which require dot-clock to be accessed). Even if mclk is stopped, doing I/O does 
not require mclk (only bus clock). 

B. In H/W Suspend, we cannot access any I/O register as the CPU inputs are 
forced to make them insensitive to CPU bus activity. 

4. During suspend resume sequence (when Nordic goes out of Suspend), as long a^ 
the CPU bus inputs are not forced internally, it is possible to execute most I/O-s. The I/O- 
s that require dot-clock should be executed only after dot-clock synthesizer is on. 
To facilitate the restore operation after suspend, Nordic has two status bits: 

- suspend status bit, that can be polled waiting for the internal suspend lermmaie 
sequence to complete 
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- power sequencing on status bit that can be polled to know when the internallv 
generated and controlled power sequencing to the Flat Panel power supplies, is com- 
pleted. 

This provides for a simple mechanism of waiting to start restoring the state after 
suspend and to know when it is OK to assume that the Flat Panel Dispiay^s on. 
Please note that when the chip goes out of Suspend state, towards the end. Panel Power 
Sequencing takes place if the chip was in panel. 

Now, let me go to the main issue: 
I think that there is a misunderstanding between us and Toshiba. I fully understand why a 
good save/restore mechanism is needed. I understand that in a password system a mode 
change may happen before actually restoring the data as it was before suspend. 

Where I think that we mis-communicate is when we are told that Toshiba needs to do the 
actual save/restore operation "while in SUSPEND MODE". 

In our model of thinking, 

- the state should be saved first, 

• then the Suspend pin should be assened, starting the internal process of puttmg the chip 
in suspend, 

- while the chip is in Suspend Mode no CPU access to the chip should happen, 

- the first thing to do when going out of suspend is to de-assen the suspend pin and start 
polling the Suspend Status Pin or the Suspend Status bit until the internal sequence of get- 
ting out of suspend is completed. If it is desired to change the mode before sianmg the dii- 
play, than the LCD enable register bit can be disabled before going in Suspend. In this 
case the Flat Panel will not be power sequenced after coming out of Suspend. 

- now s/w starts accessing Nordic and programs the graphics mode and Video Memory for 
password display. 

• After the password is given by the user, the original Nordic state is restored. 

I do not understand why at any moment there is a need to actually access the chip while it 
is in Suspend Mode. Save state should be done before the chip goes into suspend. Restore 
state should be done after the chip goes out of Suspend state. The Suspend pin should be 
controlled by the CPU through an Output port and not by the lid switch. The lid switch 
that uiggers the Suspend sequence should interrupt the CPU and should get the CPU to 
the Restore operation. 

Please note that Save and Restore are Video BIOS calls. 

We need to close this issue ASAP. If it turns out that we actually need to access the 
chip while in Suspend Mode, the suspend current will be higher than what we can get 
otherwise. 
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Q3: PAL Output Support With Analog Encoder for IBM 

a. We are planning to suppon AD720 and MCI 377. 1 heard aboui a pan AD7:2 but I 
do not have a data sheet yet. We can suppon any pan that requires Composite Sync, a 
selection of NTSC/PAL and a Power Down pin. 

b. AD720 is 281ead PLCC (P-28A with a print of 12.45mm) 

MC1377DW is 20 lead case 751D (SO-20L looks like a small surface mounted DIP. 
but I do not have package size yet). A plastic DIP is also available. 

c. Nordic will use CRT analog RGB outputs to suppon the encoders. 

d. We'll present an application note on how TV-OUT option. We will not require e.\ter- 
nal switches. 

It is imponant to remember that the CRT monitor has 75 Ohm resistor at the RGB 
input. The DAC output has 150 Ohm resistor close to it . Together in DC they make a 50 
Ohm resistor. With this load the DAC delivers 0.7V full swing for a 6.6mAmp IRef. 
If the CRT Monitor is not connected, the load is 150 Ohm and the full swing DAC output 
voltage is 2. YV for the same IRef. AD720 required input voltage is 0.7V while MC 1 377 is 
l.OV. 

There are three ways to connect the video encoders and the CRT. We are now in the pro- 
cess of deciding which one is the best: 

1. The simplest way to connect the TV decoder is to assume that the CRT 
Monitor should not be hooked to the notebook computer at the time the TV is. In thi^ case 
we can put a high resistance voltage divider (2K0hm) to get the required 0.7V or 1 .OV 
full swing to the decoder. The 2K0hm voltage divider will not practically affect the 50 
Ohm resistance on the CRT, when the CRT is hooked on. The disadvantage of this method 
is that it requires a CRT to be disconnected from the note-book computer when connecting 
a TV. The TV encoders get RGB input through an AC connection (a capacitor) so the DC 
source may be a high resistance. 
The advantage is that it is simple and low cost. 

2. There are no buffers or other resistors than usual. We control the RSET resis- 
tor value on the LM334 current source depending on the presence of the CRT Monitor 
hook-up or not. If the CRT Monitor is not hooked-up, we adjust IRef so that DAC-s full 
swing output voltage is 0.7V (or l.OV) with a 150 Ohm load. If the CRT Monitor is 
detected to be hooked up, RSet will be left as it is now. The adjustment is done automati- 
cally with a transistor. This approach requires a programmable output (from Nordic or 
Core Logic) to control RSet value. The detection of the CRT Monitor presence is done by 
s/w the standard VGA way. 

3. Put 50 Ohm load on the DAC output and feed it to the TV encoder and to an 
Analog Voltage Repeater that drives the CRT Monitor RGB lines. This way DAC output 
is always 0.7V full swing independent if the CRT Monitor is hooked to the notebook or 
not. 

This approach works for AD720 but not for MCI 377 which requires IV full swing. 
With this approach the presence of the CRT monitor cannot be detected VGA style 
(incompatibility issue ?). 

e. Nordic does have a progranunable output pin to select PAL or NTSC to the 
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encoder. 

Ii also has a programmable output pin to control TV encoder power-on ( AD7:0). 



Q4: Additional Address Lines 

A4: Nordic has now in VESA VL bus addresses from 0 to 25. We called addresses 24 and 
25, HIMEMO and 1, because one can hook any of the upper address lines to it f for in'stance 
addresses 31 and 30). 

Three possible ways ro connect an Analo g PAI7NTSC TV Encoder rn HAP nnrp-.r 
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R,GorB DAC output 



150 
Ohm 



X 

X 




CRT Monitor 



2.1V max 
with CRT 
disconnected 



1.4K0hm 



TV 
Encoder 
AD720 



X 

CRT Connector 



0.7KOhm 



D 



150 
Ohm 



1 



<> 



75 
OhmY 




CRT Monitor 



Automatically Adjust IRef to get 0.7 V max 
if CRT not cormected and D.7V max if 
CRT is connected. 



TV 
Encoder 
AD720 



0.7KOhm 



CRT Moniior 



3. 



0.7V max 



50 

Ohm 



X 
X 



r^> ^0.7Vmax CRT C onnector 



Analog Repeater 



75 

Ohm 



X 




TV 
Encoder 
AD720 



0.7KOhm 
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IBM 



i^X'Oi^m^tn f 160 iJRBRSSBMe-K-t Tel: 03 -3340- 9m"-,; fii.C3^3340-r::c 



Mr. Ahmasa Naitoh 

Manager of Notebook Product Development # 1 
Portable Systems, PS Products 
IBM Japan Ltd. 

1623-14 Shimo-tsunima, Yamato-shi 
Kanagawa-ken 242, Japan 

Dear Nahoh-san: 

I believe that there is tsow regular communicaticBi on Nordic ♦^^hni^l specifications between 
your e ngineers and ours. In tenns of the video roadms^), I would like to present an overview to 
you on January 19 followed by a detailed presentation tiue week of February 7. 

In this letter I will focus on the specific questions you raised in your tax: 
I. Pricing 

Based on an a"""^^ quantity of 50-lOOK, wie can oSer the following pricing: 



2. Schedule 

As a result of the discussions with your engineers, we have made some changes to the Nordic 
design. We are now expecting to tape out the base layers by the end of F^ntaxy and receive first 
silicon in early April. Depending on how many problems we fi nd , we will be able to provide 
initial samples between mid-April and eariy May. 

Because we have removed several complex features from the design(tbe WavePort and video 
port), we remain confident, however, in our ability to provide I0-20K production units in July. 
We will be happy to share our schedule with you in greater detail if you wish. 

3. Performance 

Our performance assumption is based on measurements using the GD5428 VL-bus 
denx)nstration board. With 1MB of 70ns 5V DRAM and 50MFIz MCLK, we have achieved 24- * 
25 million WinMarks under WinBench 3.11 and 8-9 million WinMarks under Winbench 4.0 at 
640 X 480 resolution, 256 colors in a 66MHz DX/2 system. Cirrus Confidential 
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Q3 1994 
Q4 1994 
1st Half 1995 
2nd Half 1995 



$31.00 
S 28.00 
$ 26.50 
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While it is true that tbe DRAM in Nordic wiU also serves as a frame accelerator, the frame buffer 
is ooc rsquirsd when Nordic is driving TFT or stogie scan STN panels. In this case, Nordic will 
drive the CRT and LCD panels at the same dock speed so there should be oo performance 

The frame buffer is only utilized when a dual scan STN pai^ is being driven. However, our 
memory architecture allows the memory azxi CPU ioterfue to remain 32-bit even when the frame 
buffer is used. As a resuh, the per^Hmanoe degradation should be less than 15%. This is 
substantiated by the attached perfbnnazMe comparison of CRT versus dual scan color STN LCD 
perfbnnaooe for ooe of our current controllers, the GD6440. 



4. Early Evaluation Board 

We are plaxmiztg to have a Beta versioo of the Nordic BIOS available with the first sample. The 
way we can achieve this is to dieck tbe CRT fimctioBaitty of the BIOS using the desktop 
cootxoller. the GD5428, on which Nordic is based. When we have the Nordic silicon, we can 
concentrate on testing the functions added to tbe desktop base including LCD panel inter&ce, 
power management and PCI interfiioe. 

Using a simular procedure, IBM can first review the GD5428 BIOS kit and then start system 
BIOS devdopment using the Nordic register information we will provide in the first wedc of 
February. The CRT fiinctionality of the BIOS can be verified using the GD5428 demonstration 
board prior to receiving first samples of Nordic. 



5. I/O decode 

Our original implementation for address drrortmg supported a physical address space up to 
maximum of 32 MB without the use of external logic. The specific pins were BE[0:3], 
ADR{2:23] and the HIMEM 0 pin. Since the WavePort has been removed from the design, we 
have added a HIMEM 1 pin for direct suppoit of up to 64MB physical address space without 
external drmding logic. 



I hope this informadoQ is helpfiil. Please let me know if you need any additional information. 

With my best wishes for a successfiil New Year, 
Very truly yours, 

Robert V. Dickinsoo 
President, Cirrus Logic K.K. 



CC: Mr. Kimio Fujii 
Mr.DelMank 

Mr.JunichiNujima Cirrus Confidential 
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Memo 



TO John Niijima • CLKK 

FROM: Vlad Bril - Cirrus Logic Inc. Ref# VB-NORDIC-J003 

DATE: January 14, 1994 

RE: Questions on Nordic #3 

CC: Dennis Jow, Bob Conner, Bob Dickinson, R. Han, Del Mank, T. Wada, T. Ho 



Thank you for your fast answers, 

Commenis and Answers to your fax JN9401-03 1 2 pages. 

1. So the SLEEPIn pin issue is closed. Either the selected s/w port or the sleep pin will pui 
the chip 10 sleep. 

2. Reset Pin Polarity. In your comment you imply that RESETn will be floating during 
Suspend unless I pull it up somehow. This answers one of my questions on what happens 
to the RESETn pin when the system goes in suspend: it is floating. 

If this is the case, I can disable the RESETn pin as I do most other CPU Inputs (you 
remember the NOR input buffer I explained in last fax). This will force my internal 
RESETn H. In this case, you have to go out of suspend before trying a warm boot of the 
system. Is this OK? 

Could you send me a list of ail the signals that are floating during suspend on the CPU 
bus that goes to Nordic? 
What happens to 32KHz pin is it floating too? 

What about TRWn pin or OSC pin, or even SUSPEND Input pin itself. This pin puts the 
chip in Suspend... it should not float! 

3. Access to RAMDAC temporary latches: 

I understand now how our BIOS save/restore routine solves this problem without the use 
of special registers for temporary latches. If needed I can explain you and Toshiba. This 
code works. 

Let's assume that the suspend request came after writing R but before writing G and B to 
the RAMDAC. 

- the Save routine executes one write to the RAMDAC with some dummy data and 
reads the RAMDAC write index to see if it changed. It will not. 

- the Save routine executes another write to the RAMDAC with some dummy data and 
reads the RAMDAC write index to see if the index changed. Now it will. Also the RAM- 
DAC will be updated with the data "R dummy dununy" as RGB in the location the pro- 
gram was writing when interrupted. 

- The Save routine saves the fact that it took two writes to change the index. This means 
that the program was stopped while writing R, so the Restore routine will use this data to 
restore only the R and then let the application continue. This way the dunrmiy data written. 
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even if saved by the save routine, will not be written in memory at restore operation 
because the restore operation will stop after writing R. 

- now the RAMDAC write index is saved as well as the RAMDAC contents from 
zero to the index. 

- the restore operation with rewrite the RAMDAC till index minus one and the R for 
the next index. 

- then it will stop and let the application continue. 

Practically all Toshiba needs to do is use Cirrus Logic's Save/Restore routine or some- 
thing similar. 

4, RDYn and LDEVn will be floating during Suspend if the power to the external pull-ups 
is turned off (they will not be L, unless you ask me to pull them low). The current design is 
pulling them L only if there is a valid cycle to Nordic. Otherwise they are not driven by the 
chip, but they are driven H by an external pull-up. 

5. 1 need data on Mode 74H ASAP. 

6. 1 talked to my Flat Panel Expert and he was surprised that Toshiba is asking for FRM of 

9bit TFT panels. I understand that 90C24 is doing this. If Toshiba requests us to do it, 

we^d like to work together with them on it. We'd need a panel data sheet and an actual 

panel they are using to do a bread-board and see what quality of shades we get. 

What is the speed of the panel they are using? Could you please get a demo and see what 

quality of shades they get now ? With a very fast panel shading with FRM is usually a 

problem. 

At present we do not have FRM for 3bii panels. Is it possible that Toshiba is doing now 
FRM only on the Least Significant Bit of the 3 bits/gun ? How do they get this 1 85. 193 
colors number? 

At present we use dither to get as many colors as the input signal can provide on a CRT 
Monitor. This way we can display 24bit and 16bit per pixel. 

The trend we see with TFT panel development is that they go towards 6bit per gun. Are 
you aware of the Peanuts program? Does Toshiba intend to stay with a 9 bit TFT panel? 
They do not go to 12 and 18bit TFT panels? My understanding is that Peanuts is relatively 
low cost. 

In any case, we'd like to work together to meet Toshiba's demands. 
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Memo 



TO: John Niijima 
FROM: Vlad Bril 



-CLKK 



- Cirrus Logic Inc. 



Ref# VB.NORDIC-J004 



DATE: January 18, 1994 
RE: Questions on Nordic #4 

CC: Dennis Jow, Bob Conner, Bob Dickinson, R. Han, Del Mank, T. Wada, T. Ho 



Thank you for your fast answers. 

Comments and Answers to your fax JN940 1-040 1 page. 

2. a. Q: What is the plan to conven from 0.8um to 0.6um? 

A: Our current plan is to have 0.6um samples in Q3'94, preferably in July or August. 
Is there a critical time window we have to hit for IBM ? If we knew when it is absolutely 
needed, we'd adjust our schedule as much as possible. There is a balance between 
improvements and features to be put in and the tape -out schedule. 



In ApriVMay if there will be some small upgrades to be made for IBM, we d be glad to. 

b. Q: Extended Data Out DRAM vendor. 
A: I know Micron Semiconductor Inc. has samples of -7 and -8 parts now. Production 
is scheduled for -6 -7 and -8 in Q2'94. The pan number is MT4C 16270. It is a 2 CAS" 
pan. It is available in 40pin SOJ or 40pin TSOP packages. 
3.3V pan is scheduled to be available in Q3. 

It is possible that Hitachi or Samsung are also working on such a part, but 1 think that 
Micron Semi, is far ahead in terms of schedule. 

3. Q: 640x480 24bpp support at 3.3V. 

A: There are several possible ways to run 640x480 24bpp. Depending on the specific 
way it can be run or not. 

a. When Nordic runs 4:2:2 YUV. it displays 24bpp though data is stored in memor\' and 
transferred to Nordic at a 16bpp rate. In this mode, Nordic can run even at 40MHz mclk at 
3 1.5MHz dot-clock {75H refresh), though 45MHz or 50MHz mclk would lead to much 
higher memory bandwidth. 

This is the preferred mode for play-back under MVA. Please note that if the MV A is used 
and the window is smaller than 640x480, a high CPU bandwidth is obtained outside the 
Motion Video Window, if MS Windows is run in 8 or 4bpp. 
This data is for TFT panels or CRT monitors. 

b. In 24bpp RGB, Nordic can run 5428 way (at 3x the base frequency) or can run the new 
Nordic wav. using the MVX 24bit wide d ata oath at U the base frequency. 

Once the appropriate driver is developed, Nordic will be able to run 640x480 24bpp RGB 
in Ix mode at 50MHz mclk up to about 27MHz dot-clock. With a 32bii wide DRAM, 
there is not enough memory bandwidth to run this mode at 3 1.5MHz. The refresh rate can 
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be improved by reducing the non-display time on a TFT panel. The lower the doi-clock 
frequency, the higher the performance. 

At 40MHz mclk, Nordic can run 640x480 24bpp RGB only at about 21 MHz dot -clock 
maximum, on a TFT panel. If 3.3V core logic has to be used in this mode, the refresh rate 
may be improved by reducing the non-display time. 

All this data is on a TFT panel or a CRT. 

A recommended way to run 640x480 24bpp RGB is to run this mode at 50MHz mclk and 
5V CVDD (Core VDD) and switch to 33V in suspend and stand-by mode. The group 
VDD-s (bus, memory, panel, CRT&TV) do not need to change. Analog VDD-s for RAM- 
DAC and Clock Synthesizers should track CVDD (they all change together). 

This restriction will go away in 0.6um technology. 

Best Regards, 
Vlad. 
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TO: Brian Howard and Mary Johnson of Apple Computer* Inc. 

FROM: Mad Bril of Cirrus Logic, Inc. 

DATE: 02/03/94 

RE: Apple's Specification • Engineering Issues - rev #2 • after getting your answers 

CC: Dennis Jow, Peter Pemice, Guido Carasso* Del Mank, Bob Conner 



Thanks a lot for your help in understanding the issues. Following is an update of the 
previous data I sent you, based cn the information you provided and answers to the 
specific questions in your fax. 

Here is a summary of the meeting we had with some questions. 

I marked ,what Nordic can do relative to the specification you wrote on the board. 

In some erases the description is not detailed enough for me to give an answer. 

Apple Spec from Brian: What Nordic supports: 

PCI Bus yes I 

LCD 640x480 I6bpp Yes. with the following maxi 

mum doi-clock rates: 



- Sharp-Color dual scan 16bit 
up to 30.24MH2 dot-cik 

- Sharp-Mono-FSTN dual 
scan - up to 26MHz dot-clk 

- Sharp Color- AMLCD IZbit 
data interface - up to 28MHz 
doi-clk 

- Hosiden Color-AMLCD 
18bii data interface - up to 
40MH2 dot-cik. if needed. 
Practically OK at 30.24MH2 

CRT 640x480 16bpp @ 30.24MHz, 67Hz yes 

. .832x624 8bpp @ 57 J832MHz, 68.7Hz yes 
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Mirror Mode 640x480x8bpp LCD & CRT Yes. with fixed frequency 

or Multisync monitors 
wiih the following panels: 

- Sharp-Color dual scan I6bii 
up to 30.:4MH2 dot-clk 

- Hosiden Color-AMLCD 
ISbii data intert'ace - up to 
40MHz dot-clk. if needed. 
Practically OK at 30.:4MH2 

Only with Multisync 
Monitors 

with the following panels: 

- Sharp-Mono-FSTN dual 
scan - up to 26MHz dot-clk 

- Sharp Color- AMLCD libit 
data interlace - up to 28MHz 
doi-cik. 

Note: a. When running on Multisync .Monitors is it possible for Apple to reduce the : 
non-display time in order to get a higher refresh rate for a given dot-clock frequency ? 



Big Endian memory space for frame buffer yes 

1 ,4,8, 16 bpp packed modes yes 

April '94 prototypes .Marketing issues. 

July '94 EVD2 (production quality silicon) 
Jan '95 production ramp 
.March '95 Intro. 
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Brian\^ Wj^h [J^t; what Nordic ^npp^n^; 

800x600 I6bpp on panels yes on TFT panels 

@ 40MH2 dot-clock, 60Hz 

refresh rate, 
yes on DS STN panels up to 
about 36MH2 dot-clock 
(about 1 iOHz refresh rate or 
better, if non-display time is 
reduced). Actually we could 
run at 90Hz refresh rate at 
lower dot-clock rate to reduce 
the requirements on the panel 
spec, and get higher pen'or- 
mance. 

832x624 16bpp on CRT Only on a Multisync 

Monitor if the non-display 
time is reduced relative to 
the standard Apple monito^s 
so that the refresh rate is at" 
least 6OH2 at 40MHz 
dot-clock. 



640x480 I6bpp both screens Yes, with both Standard and 

Multisync Monitors at 
30.24MHz with the following 
panels: 

- Sharp-Color dual scan 16bii 
up to 30.24MHz dot-clk 

- Hosiden Color-AMLCD 
I8bit data interface - up to 
4OMH2 dot-clk, if needed. 
Practically OK at 30.24MHz 

Only with Multisync 
Monitors 

with the following panels: 

- Sharp-Mono-FSTN dual 
— - scan - up to 26MHz dot-clk 

- Sharp Color-AMLCD I2bit 
data interface - up to 28MHz 
dot-clk. 

Cirrus Coafldentiai 
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800x600 I6bpp LCD & 832x624 I6bpp CRT 



- Only with Multisync Moni 
tors and TFT Hosiden panels 
at 60Hz refresh rate and 
40MHz doi-clock. 

- If a fast enough Dual Scan 
Color Panel is available, it 
may be possible to run at 
36MHz or 32MHz 
dot-clock maybe with a 
reduced non-display time, as 
even a Multisync Monitor 
does not need too long non- 
display time. Depending on 
how much we can reduce 
horizontal and venical non- 
display lime, we may get a 
higher or lower refresh rate. 



2bpp packed 



may deliver by July if 
required, not in current rev. 



S20 price @ 20-30K/mo 



Marketing question. 



Answers to Other Fax Questions: 

1. Q: Is it an option to add an extra buffer RAM to allow Dual Scan STN Panel to run a 
THE SAME RATE AS CRT in mirror mode? 

A: This is not a current option in Nordic. 

It could be done in future products. It could actually be embeded in the standard 
Frame Buffer Memory. It requires twice the amount of memory band-width overhead the 
half frame buffer approach. 

2. Q: Can Nordic drive 800x600 I6bpp on Multisync Monitors? 

A: Yes, up to 40MH2 dot clock, with a 50MHz memory clock (to meet memory band- 
width requirements). We may get 60Hz or even better, depending on the horizontal fre- 
quency range of the monitor. 

3. Q: Mirror for 800x600 LCD anf 832x624 8bpp Apple CRT? ^.^^^^ Confidential 

What about 800x600 Multisync 8bpp? Business Information 

What about 800x600 Multisync and LCDl6bpp? 
Are these only possible with single scan panels? 
A: Nordic can display only pan of the 832x624 picture on a 800x600 panel. It could 
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even pan through the larger picnire. But what panel would you use at 58MH2 dot-clock? 
Not even Hosiden runs that fast. 

If we can run the CRT at 40MH2 dot-clock or lower with an acceptable vertical refresh 
rate, we can run mirror mode as long as the panel meets the specification derived from the 
40MHz dot-clock rate. Either 8 or 16bpp is OK at 40MH2, but 16bpp requires a SOMHz 
memory clock, while 8bpp can operate at 45MH2 memory clock. 

800x600 8bpp at 40MH2 could be run with a Dual Scan Color or .Mono LCD as long as 
the panel meets the specs. 

800x600 I6bpp can be run at 40MH2 memory clock anfd SOMHz memory clock only with 
singlr scan panels. If either dot-clock is lower or memory-clock higher frequency by about 
15%, it is possible to run this mode on an 800x600 DS Color Panel. A monochrome panel 
requires only about 5% extra memory bandwidth. 



4. On 24bpp modes. 

We need to talk face to face about your suggestions. We need a board. 

1 agree that 24bit/pcl modes could be very useful with LCD panels using 6bit drivers. 
You and Bob Conner should decide in what product this will be implemented. 

(I can tell you how much work il is to do it.) 

Once this is agreed upon, we'll have the pleasure to work out the way we do it. 

By the way, would it make sense to get a 4:2:2 YUV format (YO U Yl V in 32bits per 

2 pixels) as a graphics mode? This is a 24bpp mode that requires I6bpp average band- 
width? 

64bit wide memory is certainly something you'll find in our future product line. Our strat- 
egy presentation will talk about such a product. 
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TO: Brian Howard and Mary Johnson of Apple Computer, Inc. 

FROM: Vlad Bril of Cirrus Logic, Inc, 

DATC: 01/22/94 

R£: Applets Specification • Engineering Issues 

CC: Dennis Jow, Peter Pemice, Guido Carasso, Del Mank 

Here is a sununary of the meeting we had with some questions. 

I marked what Nordic can do relative to the specification you wrote on the board. 

In some cases the description is not detailed enough for me to give an answer 

Apple SPtC from Brian; what Nordir Qiinpnrt<> 



PCI Bus 



yes 



LCD 640x480 16bpp 



probably yes but I need: 

What kind of Panels? 

Dot-clock? 

What Refresh Rate? 



CRT 640x480 16bpp @ 30.24MH2, 67Hz 



yes 



832x624 8bpp @ 57.2832MH2, 68.7Hz 



yes 



Mirror Mode 640x480x8bpp LCD & CRT 



Probably yes but 1 need: 

What panels? 

What dot-clock? 

Is it 67H2 refresh? 

Dual Scan STN Panels may 

require fast drivers. 



Big Endian memory space for frame buffer 



yes 



1,4,8,16 bpp packed modes 



yes 



April '94 prototypes 

July *94 EVD2 (production quality silicon) 
Jan '95 production ramp 
March '95 Intro. 
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Brian's WUh I Jsf; 
800x600 16bpp on panels 

832x624 16bpp on CRT 
640x480 16bpp both screens 

800x600 16bpp LCD & 832x624 16bpp CRT 

2bpp packed 

$20 price @ 20-30K/mo 



What Nnrriic supports: 

yes on TFT & DS STN panels 
@ 40MHz dot-clock, 6OH2 
refresh rate 

no (not @ 57.3MHz) 

Probably Yes, but I need 
data on panels, dot-clock 
refresh rate. 

no - mem. bandwidth probl. 
(not at 57.2MH2 dot-clock 
can run only upto 40MHz) 

may deliver by July if 
required, not in current rev. 
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Memo 



TO: 


Brian Howard and Mary Johnson of Apple Computer, Inc. 


FROM: 


Vlad Bril of Cirrus Logic, Inc 


DATE: 


01/22/94 


RE: 


Apple's 24bpp Graphics Modes 


CC: 


Dennis Jow, Peter Pernice, Guido Carasso, Del Mank 


Summary 



In the Jan. 21-st *94 meeting Brian presented us with a request for future support of Apple 
24bpp mode. This document outlines the problems and the possible related solutions. 
The conclusion is that it is possible to run Applets 24bpp mode in a system with a 
32bit wide DRAM-based Frame Buffer at 25MHz dot*clock and even 31MHz dot- 
clock. 

A for 834x624 at 57 JMHz dot-clock, the Frame Buffer should be 64bits wide and 
similar solution will work. 

This document represents a technical analysis; it is not a commitment from Cirrus Logic 

to implement these features as described. i 

This document should be kept confidential under our Non-Disclosure Agreement. 

Analysis of Memory Bandwidth Requirements 

Given the fact that the fastest 256Kxl6 DRAM available today has a page cycle (TPC) of 

40ns and a random cycle of about 130ns, is it possible to run Apple's 24bpp + alpha mode . 

at 25MHz (60Hz refresh) without reformatting the data in memory? 

As one memory fetch (32bits) represents one pixel, and each pixel is fetched every 40ns, 

the average memory fetch cycle time (assuming a mix of random and paged cycles) 

should be less than 40ns, in order to execute some CPU cycles too. 

With a TPC of 40ns (equal to the time a pixel is displayed) this is impossible. 

Assuming a large CRT-FIFO that ensures 16 CRT memory fetches in a row, what is the 
maximum dot-clock frequency this could work at? 

R+I5P = 7m+30m = 37m = 740ns to fetch 16 pixels -> 21.6MHz dot-clock. 
With a controller that can run a TFT panel with almost no non-display time, this may still 
provide 60Hz refresh rate, but the CPU performance will be low. 
To get a decent CPU performance, we should execute at least one CPU cycle every FIFO 
fill, which leads to: 

R+R+15P^m=880ns to fetch 16''pixels -> 18.2MHz dot-clock which will reduce the 
refresh rate to about 55Hz even with no non-display time. 

To run an 834x624 24bpp + alpha charuicl mode at 57.3MHz the requirements are even 
more difficult to meet: an average memory cycle should be 17.4ns, much below even the 
future Extended Data Out -60 256Kxl6 DRAM-s (best TPC is 25ns). 
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Solution for 640x480 mode at 25 MHz 

The proposed solution is to reformat the data in memory by eliminating the alpha channel. 
This should be done fully transparent to the CPU. This will increase memory bandwidth 
by 25%. 

This solution was talked about in the meeting, but it was not obvious how data reformat- 
ting can be done in a transparent way to CPU. 

The solution proposed here is not trivial to implement, but it is possible. Td rank the 
design complexity as average. 

The idea is to remap the data to and from frame-buffer memory based on the CPU 
Address bits 3 and 2. Each possible combination of these two bits will require a different 
way of accessing the memory in terms of number of memory accesses, memory address 
and bytes enabled for access. The result is represented in the following figure: 



CPU 
32bit 
Address 
0 



2 
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CPU Data 
31 0 
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Memory Addressing Scheme 



MAO, bytes 0:2 
MAO, byte 3 + MAI, bytes 0,1 
MAI, bytes 23 + MA2, byte 0 
MA2, bytes 1,2,3 



With this approach, the minimum memory clock frequency to run 640x480 at 25MHz 
deadlock is 44MHz, while an optimum frequency is 52.5MH2. 
With this CPU Data reformatting approach it is possible to run 640x480 24bpp at 
about 25MHz dot^lock with 256Kxl6 -70 DRAM-s with Page Cyde of 40ns. The 
performance is close to optimum. cirrus Confidential 
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To run the same mode at 31MHz dot-clock, though the minimum memory clock fre- 
quency is 54MHz, the optimum is 65MHz requiring a page mode cycle time of 37ns 
and 30ns respectively and a -70 or -60 Extended Data Out DRAM. 

These calculations assume a reformatted 24bpp memory format. 



Solution for 834x624 at 57.3MHz 

At 24bpp this mode requires 1.5MB of memory anyway. The optimum way to run ii is 
with 2MB of memory 64bits wide. 

Even with 64bii wide DRAM you*d need a 13ns TPC to run this mode in the standard 
Apple format in an optimum way (15ns TPC minimum). 

If the data is reformatted by removing the alpha channel, with a large CRT-FIFO 
you can get to a minimum of memory clock frequency of 50MHz and an optimum of 
60MHz, which is well within reach with a -70 or -60 EDO DRAM. 

The design of the reformatting circuitry for 64bit wide memory is more complex than for 
32bit wide memory because it requires more cases to be covered. 
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